Automatic IETF Minutes

Markdown Version

Session Date/Time: 24 Jul 2026 07:00

[00:00:05] Wes: Claire's here. Morning, Claire.

[00:00:11] Claire: Wow. That was an echo.

[00:00:15] Wes: There are not many people in the room today.

[00:00:17] Claire: I do see.

[00:00:19] Wes: Yeah. And and we have a room of, you know, 300 seats or something. So 270 seats. But

[00:00:26] Claire: I was mildly surprised as to the cost of a single day ticket, I will be honest.

[00:00:32] Wes: Unfortunately, I can't hear that over Andy and Thomas talking. The room is very echoey.

[00:00:38] Claire: Yes. That's coming through this side as well. No. I I yeah. It's I think given that our group only attends this session, the the cost of a single day ticket, certainly, from my perspective, was quite prohibitive.

[00:00:53] Wes: Yeah. That's You know, the encouragement is that you're supposed to come for the full week. That's why single day tickets are expensive. Anyway, we'll give it another minute or two because it's early in the morning. Judging by the number of tired faces I've seen this morning with people, like, barely struggling, we'll give it another few minutes.

[00:01:15] Claire: Yeah. I I will I will say it's it's 8AM here, and I'm on my second cup of coffee, so I'm I'm about there.

[00:01:21] Wes: Right. Do you wanna do the chair slides? We didn't actually talk about that ahead of time like we normally do.

[00:01:28] Claire: Yeah. That's that's fine. Okay.

[00:02:21] Wes: Let's go ahead and and give up. I think we had more people on the Shenzhen meeting, but that's okay. Why don't you go ahead and get started, Claire?

[00:02:30] Claire: Certainly. Hi, everyone. Welcome to the SATP working group. Myself and Wes are your chairs. It's weird talking to an empty room on screen, but I can see lots of people in the list. So I'm feeling this is reaching people. Could someone move the slides across? Oh, no.

[00:02:49] Wes: I can I gave you slide control, so you should yeah?

[00:02:51] Claire: Yep. Got it. So typical note. Well, everyone have a a quick read through. These are the fairly standard processes. They can be found online. And the IETF docs that we strongly urge anyone that hasn't reviewed to go away and do review. They're quite pertinent to how we work. Again, session is being recorded. If you are in the room, you can log in. If you're not in the room, hi. Welcome. And just be aware that you are being recorded. So just keep that in mind. Again, more information about us, where you can find the documents on the data tracker. A reminder of our purpose, this is sort of a phase one of developing a protocol to transfer digital assets from one different act from one asset network to another asset network. So this is a single one way transfer. I probably need to change that wording there between gives you an idea that it's multi way. We have three active drafts in a pretty healthy state, and we are looking at the review stages right now. So we've still got a few more stages to go. But I think from Wes will back me up here that as as a as a working group that hasn't done IETF before and is unique to this particular group, I think we've moved through pretty fast. Although it it feels like we've been doing this for a while. Apparently, our our IETF terms, this is this is pretty quick.

[00:04:23] Wes: Yeah. One real quick comment. I forgot to warn you about this slide. So so we have gone through working group last call. We've had one AD review. I don't remember. Andy, have you read them yet? Okay. So right. So we've we have actually had two AD reviews from two different ADs, which is great. Next slide, Claire.

[00:04:43] Claire: Yep.

[00:04:44] Wes: Because we are going to greatly revamp the error section, which we're gonna talk about a little bit later today, the core document probably needs to go through back through a two week working group last call just to give everybody one last chance because that's a pretty major change. Yeah. It's easy to do. It'll be short, but we should probably do that. I'm assuming Andy agrees with that as well, but that's that's sort of the right thing to do. Yeah. So but that that'll be easy. And I think once we get done with the error stuff, which will probably be in the next couple of weeks, we can start that process. Alright. Thanks, Claire. I don't I think there's only one slide left. Yep.

[00:05:25] Claire: Fab. So introduction and that current document status well, current document status with the office of Unix. Thank you, Wes, for that that clarification. That's super helpful. I think having that flow is is is really informative to those of us that are new to the process. And then we will dig into the meat of it. And then we've got a few presenters today, all of which I can see here. So that's great start. So on to the next slide deck then, please.

[00:05:52] Wes: Alright. Thank you. I gave Thomas the clicker, and give me one second to

[00:06:10] Thomas: Morning, folks. So just a quick update on core based on comments from Andy, the AD. All this time, we just we forgot to change the header. This is the last thing. The first page is the last thing you ever read. So it's it now reads proposed standard. And there were a couple of, you know, just typo mistakes in the JSON examples. There were a lot of all the examples had stray backslashes. That is an artifact of converting from dot m d to the text. So we're gonna that's already been fixed in version 14. BCP language, that was very important. We just had must and should in lowercase, and and we we do mean the the must and the shoulds, so they're now, like, capitalized. And all the ID in it issues have been taken care of. They were they were thank you, Andy. There were non ASCII characters everywhere. So I don't know why maybe parts of it were copy and paste from Microsoft Word maybe. So so that's those are done. I think the only thing I want I would like to okay. Before I forget, the only thing in one of the comments you had was the IPR disclosure. So I think don't I know who you you need to tell the authors, hey. Put out your, you know, IPR release thing. Right? I did I think I did it, and I think Rafael did it. But I don't if the other authors actually know that they actually have say that. I

[00:07:52] Wes: mean, that's actually not commonly done and we probably need to do it more. Andy's right there that that should be done. That being said, I think most of the IETF doesn't do that, which is a problem. Go ahead, Andy.

[00:08:06] Andy: Yeah. I think it's in the Shepard's write up about about asking them about checking the IPR. And Wes is right. A lot of times, it's just not done, but the the it is something we should actively make sure we the problem is we don't wanna be surprised.

[00:08:19] Wes: So Yeah. And and the reality is by participating and reading the note well, you've sort of already done that to some extent. But making sure that we've actually done it, I think, is a very good point.

[00:08:30] Andy: Yeah. I mean, 95% of the time in the ITF, no one's got IPR anyway.

[00:08:34] Thomas: So And and we've been showing even before this was a working group, in the eighteen months leading to it, every, like, almost biweekly, you know, informal meeting, we we would show the BCP slides, the old one. So so everybody attending knew about about this coming. So yeah. Before last thing is the URN format. So this has been a a preference discussion. I think I think we're gonna settle for this one, which is just group. And then inside group, it'll just be divided by basically what and function. So so core stage zero, we'll we'll rename it. We we don't really have a stage zero draft right now. But yeah. So that's

[00:09:19] Andy: So Andy Newton again. The the have you talked to the URN people about this? I just wanna make sure. Because thirty six eighty eight, which I think is the params, ITF params URN registry or whatever, that's the thing that's more commonly used. So I'm not saying this is wrong. I just am not familiar with the processes around doing it this way.

[00:09:43] Thomas: So yeah. Okay. Let me follow-up with the u URL. Okay?

[00:09:46] Wes: Yeah. So 30 six eighty eight is the XML registry. Is that the one you're talking about?

[00:09:53] Andy: Okay. Maybe I'm confusing things. Is this is not going into XML. Right? This is just No.

[00:09:58] Thomas: No. No. No. No. It's yeah.

[00:09:59] Andy: Okay. Yeah.

[00:10:02] Thomas: It's it's a con it's it's convention. Yeah. It's a we wanna do the con the ITF convention. We're not quite sure what it is because some documents have got params, and some documents don't have params. May maybe we're just looking at the

[00:10:17] Andy: So, I mean, it's 20 IETF URN namespace.

[00:10:21] Wes: 2648.

[00:10:23] Andy: Okay. So okay. So you've got that too. Okay. Good.

[00:10:27] Wes: Maybe. That was a very quick lookup.

[00:10:31] Thomas: And and that's it. That's the quick update for no change in architecture. We fixed all the comments from last time. Think the the big one, of course, is, you know, the error section. Thank you. Thank you, Martin. So Martin's gonna thank goodness somebody's looking at it because when we were doing the error section, it the the tables got pretty long. So, anyway.

[00:10:53] Andy: Anyone else have any questions? Alright. So that is so that was for core. Correct? Yes. And so I have the use cases and architecture document also in revised ID needed. So

[00:11:09] Thomas: Okay. No updates on architecture for this ITF, but I'll I'll take a look. And and use cases, I think if Rama is online, maybe Rama can chime in.

[00:11:19] Andy: Yeah. So I have those I have those who is marked as revised ID needed. Apparently, my I 80 evaluation, I found something I thought needed to be updated. And just to let you know, I'm I'm gonna hold all three and send them all three to the IESG at the same well, actually, the last call at the same time.

[00:11:37] Wes: Yeah. That's fine. Rama?

[00:11:41] Rama: Yeah. Sorry. I didn't get time to push an update on the use cases, but Adi's comments are well taken, and I'll address them very soon.

[00:11:51] Wes: Okay. Easy to So you're done? You want the next deck? Okay. Move slides, add alright. So, Martin, you are up. I only pass you slide control. You should see little buttons on your deck. Yes. I can I

[00:12:19] Martin: can see them? Thank you. Can you hear me?

[00:12:22] Wes: Yes. You're good.

[00:12:24] Martin: Good morning, everybody. Good morning, Paris. It's about errors, so I should correct myself. Good morning, Vienna. It's about

[00:12:37] Wes: We're

[00:12:37] Martin: playing. SAP core. And let me see if this actually works. Errors errors are are usually a dark corner in many things, and it's an afterthought. You you don't really first think about errors. And especially in the Internet protocols, this is this famous robustness principle. Be conservative in what you send. Be liberal in what you accept. So if I said, good morning, Paris, you would gladly accept it and say, yeah. He probably meant Vienna, but I take I take that. So and this may lead to to suppressed error conditions and acceptance of nonconforming messages, which would be actually very bad in the secure as a transfer protocol because security means you have to check check errors and be aware of them and handle them. And, especially, we are talking not to humans here. We're talking to to APIs and to to machines. So but we need to audit all the actions, so errors need to be machine and human readable. And so we have we have codes with message catalogs. We have descriptions, and we need to reference a context. And, usually, we have to say who is at fault or at least to guess in a conversation. In many cases, it's not clear who is at fault. The who is at fault is always from some perspective. And here, it's from the perspective of the one who checks the error. And, of course, we want them to accurate, precise. We want errors to be helpful and considering that APIs are for programmers, not for end users, and we want to be consistent across implementations. So error four hun four zero four needs to mean not found in old HTTP context, not in some implementations meet needs to mean something entirely different. That's why we have standards, and that that's why we register errors. So in looking back, we the first error handling in in on the web with HTTP was the status, which says what happened, whose fault it is, as I said, according to a reporter of the error. But it would be very useful to know when did it happen, in what context, which resource was involved, and for all the stability and tracing, which is important, our protocol, why did the transaction fail? And there's a there's a standard for the status code which are registered, which basically answer have some error codes. Basically, servers are in the 500 server side errors are in the 500 series. If the server thinks the client is at fault, it's at in the 400 series. But that doesn't stand the base much. All the all the rest is sort of free form. And in in SATP, using a JSON body, which explains explains some of the details we think they are relevant, but that's not standardized. In our standard, we we we say that. And as no. That's that's not a comment to that one. Or we'll change them all the time from where does that refer to what I just said?

[00:16:37] Wes: No. No. That was back and forth with Andy about the document status.

[00:16:40] Martin: Comment section. Sorry. And but then there's a standard did this need to have standardized and more machine processable error details was recognized? And there are two RFCs that the current one is the 9457. There's a predecessor. This one is just going a little bit more structured for more details. It provides a structured standard format. It can be JSON or XML. Of course, for for our purpose, everything is JSON. And there are a few defined fields which I detailed here in in blue on the right side. That's a typical typical error message application. Do I have a car? You can't. No. You can't see my I don't I don't need a pointer. You see the the HTTP status field on the top, which is four zero three forbidden. We this is reflected also duplicated in the status field in the body in the JSON. We have an error type, which is unique. We have a human readable title and detail. We have a field called instance, which is optional, which may refer to what resource actually is affected by this error. And then we have in green on the slide extended fields introduced by the actual use case by by the users of error. They are not standardized. Here we have we're talking about accounts and overdrafts. We have the balance on the accounts and the accounts affected. That's the channel setting. And I I've seen I stumbled across these these these standard in some quite unrelated context. Then I said, let me check SATP Core, the prod core document whether we we use them actually or whether we could use them and found that, no, we don't use them. And and it's the error handling is dispersed and described in quite a few sections. There are two lists of there were two lists in in draft 13. There were two lit chapters lists of errors. The 13 dot one was way more complete. It was a long list, but all the references from the from the stage descriptions themselves pointed to to the chapter of with about five conditions which were not complete. There were some overlap, but neither was a subset of of the authors. And the error details were all in a custom JSON structure, but not not any any standard not following any standard. And the list was to be registered with Ayana. So it was supposed to be all the error messages were supposed to be registered. So I wrote up to the mess to the to the mailing list and peep despite. I detected that quite late, and I'm very sorry about that. But people encouraged me to to write it up. And especially Rafael Belkior did a lot of work in he encouraged me to make two issues, and then we we put it forward from the issues. And he did some work, and I did some work. And we did basically the following things. We first did a a cleanup in the sense that we have a single error table, correct references to that table. And then the second thing, we use RFC9457. So the error message on the right side is an example what we we do with our messages. We changed a lot of the status for we had 400 sort of that's a catch all invalid request for almost every errors, and we assigned them to unprocessable entity, which means there's something invalid in the format of the body content and some four zero fours, which means we have a reference, which is which is in invalid points to no. Which is not found points to something which wasn't known before. And we have we we retained all the message types. And as as Thomas said before, we might need to do revise the the of the types and message types. We have we introduced the statuses. We retained all the titles we put, and this is the thing we might discuss. We have to transfer context ID. And in in a sense, this is the most important ID in in in the messages or identifying one, and I decide to duplicate that as an ins as the instance. I wanted to retain to transfer context ID because nobody nobody just looking at SAP would buy on their top of their head, know what the instance was. But I wanted to do the instance as an optional item to just confer that we are if if there's tools using the standard and interpreting this thing to the standard, we feed those tools as well. But that's that's we can discuss. All the rest of the fields we retain, I didn't change anything context context wise. Then we I I I wanted to to do a second second second thing. Error messages are for various stages are described in various various details. One stage, stage one has has an actual example. One stage has just a few descriptions with different fields. One included a version field. They also didn't. And I I said, let's let's try to merge all error handling, the the, really, the meat of the description in one chapter and add just references and mention specifics where they occur in the in the other chapter. So we did several pull requests, and I think the last the later part let me let me go forward. We merged we merged all all these. I've noticed yesterday the Rafael unwound the stage one once and put in the old versions he wrote on the request of the area director. So we have to see why is that actually a content reason or what was the reason for that. We're I also removed various inconsistencies and overlaps. And what I said, there's now a sing single table of of error codes. And I'm I'm really unsure, and I would like to discuss that. Do we near really need to register the old errors in with Ayana? Because my my reasoning is why do you want to register? Because you might run into a conflict. Somebody else might use some code. If if somebody said, I would you want to use port 80 for something very different than HTTP, you can't do this because it's registered. It's a contested space, and several bodies are are trying to to use the same space. So you register and reserve reserve certain identifiers. What we need to register is, I think, our namespace. But as long as we don't have the possibility in our standard that somebody else uses the same space, I I believe that we don't need to register them because it also takes away the flexibility. We cannot we then always have to reregister new ones. But that's not my domain of expertise. I just want to mention that. I didn't do a thing in the in the current draft to to change any of this. It says there will be a register. That's the one thing I would like to to have your opinion on. And the second one is sort of this is

[00:26:20] Wes: some don't we stop at the at the previous slide and and discuss that real quick?

[00:26:24] Martin: Yeah. Please.

[00:26:28] Wes: So you are correct. The important thing is that two implementations have to understand the same error code. Right? Otherwise, interoperability does not happen. Whether or not it's registered or not with IANA is as long as the document specifies that these are the error codes you have to use and it's within, like, the SATPURN space, I don't think it has to be registered within IANA except for the namespace itself. I'm not a URN expert. It looks like Andy is getting the microphone, which is a good thing. Originally, I asked you guys to make an IANA registry because you were defining a unique set of codes. And the one thing that you need to think about is not just this document. When there's 50 extension documents later, they all have to be unique and ensure interoperability and stuff. Andy, go ahead.

[00:27:27] Andy: Yeah. So I I I think the tension here is do we want an INA registry or not. Right? So this is writing on top of HTTP. So you're gonna get those status codes, which you have to pay attention to, 200, four zero four, 400, whatever. And then this is just an extended error code that an application may have a better way of handling or or another way of a refined way of handling. Right? So if you get back a four zero four, that means whatever you were trying to do is not found. Right? And then the extended error is gonna be, I don't know, you know, don't know what your currency is. I don't know what the whatever. Trying to come up with a good one

[00:28:06] Martin: for It's a field in the.

[00:28:08] Andy: So yeah. Yeah. But if you want the IANA registry, the the reason you would do that is because there are other people who are gonna come along and define some extended errors that you just haven't thought of today, and it's gonna be but but the four zero four is still the overriding error. Right? That's the that's the main category or the main type of error, the extended error is just another way of identifying further information about it. So that's why you would do the IANA registry. If you don't think that's a good idea because it needs to be well, basically, you need I IETF consensus for defining new extended errors, then there's no sense in doing an INA registry.

[00:28:47] Wes: But but in this case, those extended errors are the key that the implementation will actually be looking at because it'll because the HTTP error codes will not be sufficient for determining what the application has to do from a SATP level.

[00:29:02] Andy: So in other words, the applications will be making will be taking actions specifically on these extended error codes?

[00:29:11] Wes: I believe so.

[00:29:12] Andy: So to me, that doesn't sound like a good thing for I mean, you can do it in an IANA registry with specification required, and then other people can define these things and say what what the intended requirements are for the app for the applications to interop. That's the working group's choice. I just hearing this, I think this is not something you wanna do, though. Right? I I and and it depends. Do you guys wanna come back to the IETF every time when you create an extended error? That's So If you don't, do do go the INR route with specification required. If you do, then don't don't bother with it at all.

[00:29:47] Wes: So so maybe, Martin and Thomas especially, the right thing to do is maybe register the URN for satp, and then after that, register error colon so that is reserved for where error codes come in the standard space. And then you don't need to necessarily register every little tiny error after that as long as the prefix is unique. And then Yep. You know, after that core or whatever else you said so that you can guarantee nobody will duplicate that in the future.

[00:30:21] Martin: Exactly. That's what what I wanted to propose.

[00:30:25] Andy: So there's a uniqueness issue around these things too. Right? So it's another reason to do it. Yeah. Yeah.

[00:30:30] Wes: Yeah. As long as you end up in a space where no other document can duplicate or and and, you know, private error codes in implementations are common too, you know, and then you you have to make sure you define in the document what happens if you get an error code that you don't understand, which I think I wrote into my chair review a year ago.

[00:30:54] Martin: Be tolerant, the intern John John Postel would say.

[00:30:59] Peter: Yeah.

[00:31:00] Wes: Okay. So Thomas has been generally nodding. He did not use the microphone for the couple words that really didn't matter. But since everybody's remote, don't let you need to stand up and use the microphone. Alright, Martin. Uh-oh. Nope. Thomas is gonna say something. Thomas?

[00:31:14] Thomas: Yes. Thank you. Thank you, Martin, for doing all the work. But, yes, we just need the prefix, and then and then the document will say what as as Martin is showing, what each error means and all, you know, messages and so on.

[00:31:25] Wes: Yeah. Right.

[00:31:26] Martin: Okay. Thank you for the agreement. I have one last slide only. Yep. And I discussed that briefly with with Rafael, but I think Rafael is still on holidays. In the document, if if you try if I would sit here, read the document, and say, now I'm going to implement this. The document is very not very specific to say which exact error is raised in which under which condition. Which error is which thing is checked first and in which condition certain errors are raised. I I found back this this famous diagram we discussed, I think, even before the working group was formed for for quite some time, and I just added little red dots there to say, here, potentially, these are error conditions. And I just want I just feel that we are not extremely precise there. But on the other hand, I also feel feel that we probably need implementations to say where it's actually me where actually more precisions is needed and and where it's unclear. And I'm very, very unclear on how this is supposed to work with an official RFC, how the sort of the experience from implementation flows back into the into into the document. So this is this is up for me a very unclear area for me. Do do we want to do something there? Do we want to leave it up to implementations? Do we want to do something right now? I think that would be quite some work, or do we want to delay that or not do anything at all?

[00:33:31] Wes: So if you expect implementations to behave in a certain manner and they need to in order to properly conduct the really important transaction that you guys are defining, then you ought to be prescriptive as possible. That being said, I want to say a year ago, think I warned you guys that documents sometimes go to a proposed status, and then implementation experience you know, makes you learn. And you come back and you revise it, and it goes back to proposed status because, you know, lessons get learned with real implementations. And you guys have such a novel, know, new use case that the chances of you getting it perfect the first time out are probably pretty slim, and that's okay. But you also need to be aware of the backwards compatibility issue of when you do a revision to a specification like this, any room that you can leave to make sure when version two of the specification comes out, you have version identification or error identification that you know you can interoperate with older versions, somebody that hasn't updated their implementation yet. But Martin, I would say, if you believe you could go back to each of the processing sections and say return this particular URL error code, I think that's critical in my humble non chair opinion just as an interoperability expert. Right?

[00:35:05] Martin: I'm I I surely could not because I'm not in in the details. I I'm not from I would need to be familiar with any one implementation. Sorry.

[00:35:18] Wes: The the working group

[00:35:19] Martin: should Yeah. Yeah. Yeah. That is correct. I understood. I personally could not because I think one needs really familiarity with an implementation to to do that.

[00:35:28] Wes: Right. So I guess my next question is to both the authors and Martin, where are we status wise? I didn't quite follow the latest document that was just published, you know, recently. I don't I didn't look at the change diff. Where are we status wise for being done? If it sounds like that the error list does need to be go look looked at more carefully and yeah. Thomas?

[00:35:59] Thomas: So, Martin, looking at the GitHub repo updates, which Rafael has not posted yet, did you wanna do additional changes? Or or

[00:36:12] Martin: No. I'm fine. I just wanted to clarify why the I put the reject message in stage one as an error, and that was unwound yesterday, and I didn't really see any traffic behind why this was done.

[00:36:32] Wes: So so, Thomas, can you go through the document? And then, like, for every time you say, you know, when you hit an error condition, just you know, it should be easy to go say return this error type. Right? That shouldn't be hard to do. It's just labor intensive.

[00:36:47] Martin: Yeah. Thomas Thomas, maybe we we get on the phone

[00:36:50] Thomas: phone call. Martin, you and I and Rafael need to get on a Zoom call.

[00:36:54] Dennis: Yeah. Yeah.

[00:36:54] Thomas: I can. Just realized the the version that I posted a week ago that has Andy's comments is actually one step ahead of what the repo the repo has. So okay. So we'll we'll get on a Zoom call and and and fix that.

[00:37:09] Wes: So so the the the converted text file is behind, not the source file. Right? The the source is

[00:37:15] Thomas: all The converter I was just manual. We have difficulties, Andy, with this markdown to our to text.

[00:37:22] Wes: Yeah. Where's the source markdown? Please tell me it's in GitHub.

[00:37:25] Thomas: It's in GitHub. Yeah.

[00:37:26] Wes: Okay. No.

[00:37:27] Thomas: No. No. It's like yeah. Okay. Yes. Version I'll

[00:37:30] Martin: The the the markup the the official version four key doesn't contain any of this work. So Yeah. It's it's not yet in there. And I asked Rafael, and he said he needs to rebuild and ask the old authors for for their okay.

[00:37:46] Wes: Okay.

[00:37:46] Martin: We we hop on a on a call.

[00:37:49] Wes: There's no AETF requirement that doc that authors keep their documents in GitHub. But do not lose changes. That would be the bad thing. Right?

[00:37:58] Martin: Yeah. Yeah. Yeah. No. All my stuff was in you see the PRs. They're actually linked in

[00:38:03] Thomas: the I don't know it's just us, but every time we go MD to text, the the figures get all munged up into one flat rubbish. Literally, a whole big figure would just be and that's why this page miss misalignment because of this. They're literally marked down marked down to

[00:38:27] Martin: The production yeah. Our production capabilities are a little bit lacking.

[00:38:33] Thomas: It doesn't. Okay. Okay. We'll we'll fix it. So so we'll

[00:38:36] Wes: There there's an RFC for everything. What, Ian, you just set off, Mike, is there's an RFC for how to do multiline figures.

[00:38:43] Thomas: Yeah. So so the three of us will go and fix this.

[00:38:45] Wes: Okay. Great. Yeah. Anything else, Martin?

[00:38:49] Martin: I have, I think, just a summary and, basically, the thank you slide and question and comments. I'm I'm I think the error handling I I was really sorry that I was a little bit later on this, but I think it makes it easier to implement. That that was my

[00:39:06] Wes: main No. And thank you for for the work you did in in bringing this forward. I think it was an important update. So, Andy, go ahead.

[00:39:13] Andy: Yeah. So I was just going back through the draft real quickly. And this is not related to the errors, but is I don't see a maybe I missed it. Is there a media type registration for this?

[00:39:29] Wes: Thomas, microphone.

[00:39:30] Andy: So so you're just gonna use application slash JSON. You're not gonna create a media type specific to this?

[00:39:35] Wes: No. Yeah. I'm not sure one is so you think one is needed because we're passing a JSON related specific structure. Therefore, we need a media type. Is that your thinking?

[00:39:46] Andy: Yeah. Generally, it's like application slash SATP plus JSON. That's what people would do, and they'd they'd register that media type.

[00:39:54] Wes: That's not hard. There's an RFC that defines how to register a media type. It's actually it's a cut and paste template. I mean, it's trivial.

[00:40:04] Andy: But your idea was you're just going to do application slash JSON. Right?

[00:40:10] Wes: Well, you have to return some media type in HTTP.

[00:40:13] Andy: Right? Some media type, and that's a very generic media type. So alright. We we may wanna talk to HTTP people, the director, about whether they think that's a good idea or not. I don't know. The the and the other thing, getting back to the HTTP directorate, is I would they have Martin Nottingham has this skill for Claude for how to how to get Claude to do an HTTP director review. And I used something similar for like that for another document and another working group, and it was actually pretty excellent because they have very well written guidelines. So I would attempt to do something like that. That way, you're not hit with a surprise during last call from the director themselves.

[00:41:02] Wes: Well, we can we can get an early director review request done too. Once you guys feel like it's ready to go, we can get that done before last call so that they they hit it. In fact, they did want it like zero zero, and they'd said, oh, this is not ready. No. It says zero zero draft. Of course, it's not ready, but but we could ask them to to do a review themselves too.

[00:41:22] Andy: Yeah. Well, so here's what Mark's gonna do. He's gonna ask you to do what I just said.

[00:41:29] Wes: Yeah. Okay. Thank you very much, Martin.

[00:41:34] Martin: Thanks to you all.

[00:41:38] Wes: Let's see. Where are we on the agenda? That was so I think, Thomas, it's you in stage zero. Right? Then participant. It's not gonna work yet. Hold on.

[00:42:03] Thomas: Okay. For folks who are new, and I'm looking at you, Andy, this is future work.

[00:42:10] Wes: Yeah. So thank you, Thomas. We we should transition properly. We are no longer on chartered work. We are on the next charter, which has been written but not yet adopted because we're waiting to get the existing documents out, but we do allow for future work presentations after our official work is essentially over. So is there anybody else that needs to bring stuff up with respect to the three documents now? No. Okay. Go ahead.

[00:42:34] Thomas: So so for those who are also new to the working group, the reason why it's called stage zero is because in in draft core, we we talk about three parts, stage one, stage two, stage three. Now we're going backwards and saying, well, we need to set set things up. So this is this is a setup phase. So sometimes people say it's pretransfer setup, which is a big deal in the financial industry, you know, when you wanna do the big use case is DVT, delivery versus payment. Meaning, usually in trades, you're paying using wire transfer. Delivery means you're delivering, you know, electronic shares. Right? So but all these checks have to occur, and that's where this is going. On the sequence diagram, it looks like we're going backwards, but this is a harder problem. We knew about this four years ago, and we said, let's just do core because that's a confined a better defined better confined problem space. This is this is a difficult workspace because it has many parts. So we've we've both boiled down stage zero into four problems, subproblems. So the we we need to validate that when a particular tokenized asset is about to be transferred, there's some way for the prospective recipient to check. Is this is this a legitimate tokenized asset? Is it, you know, whatever tokenized oil? And when I talk about non currency, you know, assets, not not currency assets like like stablecoins. Second thing is identity verification, which has been a big issue for the last decade. And and this is a and I'll talk about this slide couple of slides there. And then after we do all these checks, we want to establish what we've been calling a transfer context. So, you know, all this information needs to somehow be bound together so that neither side cheats. And then, fourthly, we then have to somehow bind the agreed transfer context into the, you know, SATP Core before SATP Core commences. Right? So this is in many ways, I I think four is probably the the the easiest compared to the compared to the other three. Easiest in the sense that we're more familiar with four because we're we're going backwards. It's closer closest to the the beginning of SATP Core. So we've identified a number of reasons backing up a little bit. We've been using the word registry loosely for those who and sometimes I say database depending on who's listening just to make sure we're not talking about DNS. Okay? We don't wanna go there. We don't wanna touch DNS. I'll I love I love DNS the way it is. Don't don't touch it. But so we've been using the words artifact registries to to mean the metadata information that supports the tokenized assets. So this is this is not the token itself. This is all the other stuff that says this token is legit. So where do where do this thing in metadata reside? It's we're just saying artifacts, the registries. And if you look at some of the older slides, we've been saying metadata registries and people like, what metadata? I said, okay. Asset artifacts registry. So we we're beginning to create flow diagrams. This is the same one, similar to the one Martin showed before, the the little one. So so and we found that to be very a very useful tool. The the latest version is up there. You'll see you'll see in the GitHub repo. It's in the it's in the figures folder. Hang on. Let me back up a little bit. I missed that thing. Yeah. We've so we've added about a month ago, we said we really need to be very verbose. We've been like, assuming this, assuming that. And verbose means we have to show there is, quote, an identities registry or an identity verifier, and we'd be just calling it IR one and IR two. There needs to be artifacts registry. A previous version of this diagram only had one registry. Right? But what happens if different sides are saying, well, my token information is in this registry, and I'm using that registry. So we have to be cognizant of the fact that both sides might be using different locations. And then as part of achieving a transfer context, there needs to be what we've been just calling this an audit log registry, a a place where I can hash all the stuff that I have so far, dump it into this log registry and append only a registry so that if there's any challenges that it disputes, there's a log there. Right? Now and we've just been calling it audit log registry for, you know, lack of a better name. So so that's that's what it is. So mess message flows, this diagram is long if you bother to look at version 11. It is huge and long because we are intentionally being very verbose so that there's nothing is nothing is overlooked in this in this flow. So okay. Here we are. Just just explain what this is. It's a metadata registry. It's what what should go into the registry? Things like schemas for asset class. So the bonds industry, you know, beginning to talk about we we call it schema. They call they I couldn't call it schema as well for specific classes of bonds. Right? And the the the big problem there is that there's what I would call bond community. So there's communities in The UK. There's a there's a guys in New York. Right? And so they might end up coming up with a different schema even though they're actually talking about compatible things. And so that problem of the schema content is it's out of scope for the ITF. They have to decide. But whatever they come up with, that signed file has to be stored somewhere, and it's gonna be in the artifacts, what we call the artifacts registries. And so they might be digitized records of real world assets. So if you're trying to tokenize, you know, real estate somewhere, you might have to scan your, you know, ownership, you know, not ownership, the map lot thing of the asset and put it up there, and so on and so on. And so part of our our interest is in is in standardizing the APIs and the access flows so that it ties in into core. The industry the world doesn't have standardized APIs for this, believe it or not. And and I think last week, I posted the news about the DTCC. I don't know if you guys know. That that is a that is a huge deal. That is a for those who have been paying attention, the the Genius Act passed last year, and now congress is going through, I think, the Clarity Act. And and this is all about just stablecoins. I think in the near future, we might see similar efforts to begin recognizing tokenized real world assets under the same probably, you know, legal regime, you know, mix of FinCEN and SEC and so on and so on as the governing governing body. So we're our eyes on that development, which is quite exciting, actually. Okay. So so this is what you know, I invite you to actually look at the diagram slowly, you know, put lots of comments everywhere. So so basically, first thing, you know, the user one is saying to, you know, the user two over the app, okay. You know, hey. You know, I'm going to, you know, deliver you this particular asset. Are you good with that? And the answer is yes, let's proceed. And so there needs to be a way to make sure that I, user one, actually own the asset. Right? So it's gonna check on chain and so on. But the key thing is it's going to verify the asset ID. So if you look at flow three and four, it's actually talking to the AR one saying, okay, does this asset ID truly exist? Give me back all the information. And that blob of information, we've been calling it TAR and DAR. So part of the effort is defining what goes in there. This is just a quick quick snippet of the relevant pieces. Next big problem is identity verification. So FHEF is or FADEF is the global anti money laundering, anti crime organization that most I think every country is a member for sure. And they began recognizing digital assets back in 2018. And in the 2018 document, they call it recommendations, recommendation number 15, specifically say the rules for identity verification for tokenized assets, these are assets, apply equally. We're using we're using the same rules that we've been using for the last fifty years for wire transfers and banking and so on in this new digitized decentralized asset world. Right? And so in our context, that means we have to have mechanism to allow user one and user two, this originating beneficiary to be validated, validate each other. Gateways are owned and operated by businesses, g one, g two. So who is the owner of g one, g two? And then if any of these things are tied up to, like, let's say, was using x five zero nine certs or diff or, you know, DIDs representing trust anchors. So who who who are the trust anchors? Right? So the operators need to be verified as well. One of the things we actually heard so in recent discussions with, you know, some money transfer operators is that so in the old days, you could always reverse. Right? So I I I send, you know, Wes I wire transfer where's the money? And Wes says, well, actually, this is not for me. This is an error. You can always reverse it. But in the ledger case, they might not be possible. So you have to get consent from the recipient, which is kinda a new thing that I don't think the industry as a whole has realized. Right? So you can't just transfer assets. Right? Yeah.

[00:53:33] Wes: One quick question. So this is ringing a lot of bells in my head for attestation of the entities and things like that. I assume that the industry has, like, you know, regular auditing levels of, you know, it must be audited every so often, and you might look into tying in rats here. Okay.

[00:53:54] Thomas: So Yeah. So so I think we we we mentioned rats, I think, in the architecture.

[00:53:59] Wes: I I believe it was even in our list of working groups we had to work with at one point.

[00:54:03] Thomas: There there no. We we had actually, like, a long, like, half page about rats, and I think

[00:54:08] Wes: Okay.

[00:54:08] Thomas: We just started, like, reducing it. It was taking up too much too much Oh, you didn't

[00:54:12] Wes: you didn't need it yet, but now you do.

[00:54:14] Thomas: So so for for folks who are interested in attestation and rats and so on, so the gateway machinery itself may need to be attested by each other to make sure that I'm actually talking to not just the correct, you know, owner of the gateway, it's the correct gateway that was designated for this particular session. Right? So so that so that's definitely something we wanna we wanna do. It helps that Ned Smith is involved in this because he's the chair of RATS.

[00:54:45] Peter: As an individual as an individual, I have a trapped in the acumen group that actually attested devices can have certificates. That's an easy way to have transport layer security and dedicated identity for

[00:55:00] Thomas: that. Okay. Any questions before I move to slides? So this is kinda a rough sketch again. You know, verify beneficiary. Right? And so right right now, this is how to manage identity identifiers is out of is out of scope for SATP. We don't intend to do identity management. I think there'll be lots of lots of identity management, you know, topics in the ITS seeing that AI and agents are becoming a theme because people say, well, what what if what if my gateway is actually an agent? It's like, okay. It's it's not in scope, so which is a good thing for us. We don't we know how to deal with that. Transfer context and the binding to that. So this is this is the point in the in the stage zero flows where both gates where you say, okay, this is know, we agree on this. We've done all the checks. We agreed to proceed. And somehow, we have to bind this set of information to the actors. Right? So this is where these audit logs, you know, become an important thing because in order to prevent, you know, one side, one gateway from cheating, I have to include a hash of whatever I found in the log to make sure that we're talking about the same same information. I'm gonna just move forward because I don't wanna get too detailed. So we're going to continue collaborative discussions. For those who are interested, you're most welcome. The four or five of us, we have roughly biweekly calls on this just to go through the flows. There's lots of discussions, which is why we got the long, long diagram. We did the same thing for SATP way back when, you know, four years ago. And then, you know, we will be requesting stage zero probably to be a work item if, you know, we do do a recharter. Oh, there's a is there a question from Martin?

[00:57:07] Wes: Martin?

[00:57:09] Martin: Yes. Thank thank you, Thomas. I have a question sort of very general. So far, I think in in in the protocol, we have been pretty agnostic towards which digital letter ledger. It will be even to the extent that it could be a complete legacy system sort of swift or or or whatever, which is not ledger based. How how far do we you want to maintain that in the schema registry. If if I think about bonds, they're basically the legal document is a a written blurb, which which is their different standards sort of to digitize them or make them sort of machine processable, but there's no agreed upon standard.

[00:58:06] Thomas: Right. So so there's two questions there. So we wanna maintain agnostic agnosticity as far as possible. So we're not gonna say anything about how to do how to implement the registry. We just wanted to find the API. We might require some features like a pen only, not hackable. Everything in it must be digitally signed, things like that. So but how you implement it, whether it's a database, whether it's a public database, but you wanna do a ledger, that's fine. And for those who are interested, the Swift is building a ledger of ledger, believe it or not. I think part partly for this function as well. But yeah. So that's the first question. I think the second question, Martin, what was it?

[00:58:54] Martin: Yeah. Could could sort of the a bond definition also be a PDF or or whatever. So

[00:59:01] Thomas: Yes. Yes. So so right now, those familiar, organizations like DTCC, this is a big depository in New York. They use a thing called the electronic book record. Basically, it's a it's a database of all entries. Right? And they become the sole controller for lack of a better phrase. And so there's no they are the default, but it's all a database. It's basically a row in a table in a, you know, SQL database. How they make that into you know, if I were to do this, I'd convert each of them into, like, assigned JSON entry and put it in a you know, remove all the ownership information and and put this factual artifact information into a registry. They're not there yet. We've we've been having discussions with them, and they're like, well, you know, we've got, like, 50 members, so things are slow with us. So okay. And so that's why I posted that news on the mailing list last week because this is a huge deal. I mean, this is you know, it kinda recognizes that that things have to if if they wanna include, you know, tokenized assets in their workflow, then they will have to extend their workflow to include decentralized ledgers. That means they have to think about additional architecture aspects for the for the future.

[01:00:27] Andy: Mhmm.

[01:00:27] Thomas: But, yeah, thank you, Martin. Good it's a this is this is yeah. Is it PDF? It'd be nice if everything was in PDF, signed PDF. Yeah.

[01:00:35] Martin: Yes. Yes. At least.

[01:00:37] Wes: Dennis? You.

[01:00:40] Dennis: Yes. Just to follow on the the comment from Thomas. So hello, everyone. In the initial stage steps of SAPI, we were talking about assets. So it's super broad in terms of the what an asset is, which means that there is a and on top, we have networks that could be from, as Martin said, from traditional, you know, database like or or multi tier web two applications to networks that could be decentralized. So in this very broad context, one of the problems that we're having is to make sure that we all understand what an asset is in terms of the semantics. Of course, this is also a very difficult problem, but the thing is that since we are talking about a standardized transfer protocol, we need to have a standardized way of expressing the semantics of the asset. So we could know between gateway one and gateway two, depending on the jurisdictions, depending on on many, you know, constraints that may not necessarily all be technical, what we're talking about, what we are transferring, basically. So that then that's the the place where the registry comes, where we could have a standardized way of expressing things and eventually agree among two parties to transfer the assets. So if it is like an institutional asset that has to have a lot of checks, There'll be many more things that we have to be defining in terms of of what an asset is. But if it is a peer to peer transfer of some assets, it might be, you know, less important to put so many semantics in it. The thing is that there's a place that calls registry in the whole architecture that allow us to define not only, you know, the semantics, but other things, but we'll we'll we'll come to to this in also in the next slides.

[01:02:33] Thomas: Thanks, Denise. I think that's my last thing. Pub, the last comment is that and it's I don't know if Ned is online. I don't think Ned is online. But one of the things that he wants to look at is for the for those who understand LEI numbers, so so legal entity identifier numbers, most businesses that operate globally will have this. It's just a number you you pay for, and the the LEI Foundation, the global LEI Foundation, Glythe, is based in Switzerland, and most companies just you you get you get a number, you know, basically. But what they're trying to do is now wrap that number inside a data structure called a verifiable LEI, VLEI, an adjacent structure. So this is why if you look at the repo, not the the draft list, you'll see a VLEI draft from Ned Smith. And this is part of that direction. One the proposal is that that section of verifying identities and identifiers could be using whatever the Glife Foundation produces with the best sort of the authority of, you know, business identifier body in the world. So we we we help them. We we we pay attention to them. We help them, you know, should it be in technical things should have been JSON, you know, should it be signed, what's the Cypher algorithms, all that stuff. But so that's also possibly another work item for the rechartering, assuming, you know, Ned is willing to put in the, you know, effort at a time.

[01:04:11] Wes: Well, that brings me to the question I was waiting for the queue to drain to ask. So speak to me in IETF terms. Right? How many you know, what what do you see is, for stage zero the documents that we need? Are you gonna is this gonna be a brand new document that that works well in parallel with Core? Have you set Core up to do that properly? Or do you need to modify Core? Or

[01:04:35] Thomas: So so it's it's designed to leave core an architecture as is. So for the next for the, you know, recharter, definitely three three documents. You'd have stage zero. You have the artifacts registry, APIs and flows, which Dennis is going to talk about next, and then possibly the, you know, VLEI identifier document, assuming Ned Smith is going to do it. That is quite complex. So it might end up being he might end up having to split because it's quite big if you look at the doing CDDLs and so on and so on. So definitely at least three documents.

[01:05:12] Wes: Okay. I mean, normally, I don't it'll be Andy's choice of what we have to do, but I don't list the the actual documents we need to do. So the the proposed charter rewrite says, you know, we're gonna work on stage zero, and and what comes out of that depends on how the working group progresses. But some ADs like a specific list of exact documents that we wanna do for milestones.

[01:05:34] Andy: You mean in the so this is Andy. You mean in the charter text itself or just as a milestone? I'm not the biggest fan of putting things into the charter text itself unless Okay. It depends on the on the working group. Are we gonna have a conversation about the milestones that are currently on the thing?

[01:05:51] Wes: We we can. So the the milestones the milestone dates are out of date because, you know, we've gone through and revamped the documents, and now we know core has to be revamped so we could go reset new dates. That's a

[01:06:11] Andy: good point. Not only that. They're they're they only list what the drafts are. They don't really say what you're supposed to do with them. Right? So then say submit to ISG or publish as RFC or something like that.

[01:06:23] Wes: Right.

[01:06:25] Andy: Okay. So yeah. So, I mean, I'm basically talking to the last bullet point.

[01:06:30] Thomas: And if

[01:06:30] Andy: I'm if this is the wrong place to talk about it, you want me to sit down, just say say so. But at some point, need to have a discussion about how the deliverables we currently have versus getting a recharter. So

[01:06:40] Wes: So you may have not been on board yet. We've written the new charter. We went through two working group sessions discussing what people want because we came up with a list of, like, fourteen, nineteen items that, you know, were, like, future things this group wanted to do. And I'm like, no. You have to pick you know, I think we ended up picking three to five or something like that. So we actually went through the process of getting the group to come to consensus around what the next charter was gonna be, and then Claire and I did work on actually writing up the charter. Yeah. It I think I sent it to you at one point. It's not a big deal, or I know I sent it to Ori at one point before that. But the deal that we worked out with Ori was we'd get the current documents done before asking to be rechartered. So I think once it's up to you. I I my sense is once they go to IESG or IETF last call, you know, maybe that's the right time to submit a new charter assuming that the documents will be basically done.

[01:07:39] Andy: Yes. So so I think the the definition of done here is what we're gonna have to haggle over. The my definition of done would be past IESG evaluation.

[01:07:51] Wes: Okay.

[01:07:51] Andy: So I I understand like like, when things go into the RFC editor, I mean, that's you know, we can't hold up a working group for that. But getting the working group to concentrate on getting the documents passed, not just IETF last call, but through the IESG, I think, is important.

[01:08:05] Wes: I I made the working groups very clear that we had to get the current documents done, and you can't work on new stuff until the current stuff is done. I think was that was that you, Andy, that was in the queue? Okay.

[01:08:20] Andy: So the I don't know. It's up to the chairs whether you wanna have a conversation in front of the working group about the actual milestones or if you just you and I just wanna talk about it, but it's up to you.

[01:08:31] Wes: Let's let them go on and and do the real work, and you and I can talk about it. Because I don't think we've had that discussion of you know, every AD wants a different list of what milestones look like. No offense to the ADs, but, know

[01:08:44] Thomas: I'm I'm done.

[01:08:45] Wes: Yeah. Okay. So Thomas, I you're done think Dennis was gonna do the next slide deck. Right? Okay.

[01:08:53] Dennis: Yes. Can you bring it up? And do you have

[01:08:58] Wes: I'm working on it.

[01:09:00] Dennis: Yeah. Sure.

[01:09:03] Wes: And I will pass you slide control too, but you can start talking.

[01:09:08] Dennis: Yeah.

[01:09:10] Wes: Oh, it's good. It looks like it did get your new deck too.

[01:09:14] Dennis: Yes. It was, you know, wrong dates, wrong with the f number, so I fixed that. Okay. So good morning, everyone. In the stage zero slash registry sub working group, we're dealing with several issues. Among them is the this ability to be able to define what the assets are, how the connection between the network and the gateways happens, and how the whole setup of the pretransfer context is happening. So the registry is a place where we need to put artifacts that are important for the execution of the core protocol, SATP protocol. In terms of the topology of the architecture, there are a few things that we could say. First of all, you know, in the original SATP Core, we assume that there are operations like, for example, a life cycle over the the assets. For example, the lock burn on gateway on network one and mint on network two. So there is an implicit assumption there that the the unit that is processing the managing the the the assets in the network should have some standard operations. So that's one of the the things that are important here is because you need somehow to establish a connection between the fact that there is an upcoming transfer from a gateway concerning this specific set of assets in the network. And typically, these are the things that have to be somehow defined before the SATP Core starts. That's where we started discussing about the concept of transfer context. So in the context, we need to have an identification of the assets in the in the networks. Of course, the identification of the gateway and the fact that there is an upcoming transfer instance that is going to start. So we need to bind this specific transfer instance to the specific assets of the network. And on the other side, in gateway two, we have to prepare everything. So in the new net in the network two, we can have any sort of acceptance preparation as, you know, Thomas also said before that you need somehow because you cannot reverse transfers and you have to have an explicit acceptance of the transfer sometimes from the beneficiary side. So all these different things, including also the the semantics of the asset because in in network one, gateway, and you may have one jurisdiction in network two, gateway to a different jurisdiction. So there has to be all this negotiation among, you know, the type of of assets and how they are transferred and if it makes sense to transfer them. So this is the original discussion about the transfer context. And implicit to all of that, it was the question of where can we look up these things. And that's where this notion of registry in terms of a storage point where we have an immutable history of things registered somewhere. You know, we we needed to have an architecture component for that. That's where this idea of registry came up. And in this diagram, we had also in the original discussion also in in SATP Core four years ago, we are talking about putting numbers in the APIs. So this famous API one, API three. So there is also in this diagram a mapping between what existed before in the in SAP core and architecture diagrams and where the network and stage zero comes. So there is a interesting architecture assumption here is that the networks operate without knowing anything. The gateways know about the network, and the gateways know about the registries. The registries also are components that exist there. They store things, and they are passive in the sense that they don't actively contribute in the liveness and the execution of SATP Core. So everything is driven by the gateway. Yeah. Please, Wes.

[01:13:49] Wes: So this is just a challenge question. I'm not disagreeing. What the rationale why you need a standardized registry versus a, you know, implementation specific per network type of thing? What what what pieces really need to be standardized? And I I would expect the answer to be you want clients to be able to wander around from one network to another or something like that. What's your case?

[01:14:16] Dennis: Indeed. So there's some of the elements on Gantt service noted in the slide. So what we would need to have a standardized way of defining semantics for assets. So whether this is a bond or something, you know, a financial instrument, somewhere you need to have a place where it is a recognizable component called registry here, where the gateways can look up and find things about typically the semantics of the assets, you know, being transferred. Other things that are important then we we saw drafts also in the context of SAPPR identification of the other components. So how do you identify networks? How do you identify the gateways themselves? So a place to store in an immutable and indisputable way and verifiable way. All these kind of artifacts is naturally, you know, the place of of the registry. And on top, you need to have also just for execution needs of the liveness and and safety, you know, properties of of SAPP. You need to also register things like logs, the transfer context, and other things so you could recover from failure, for example, or you could make sure that all the entities agree on the same thing to transfer. So these are examples of artifacts that are necessary to put in in a registry. Don't know if I'm answering your question, Wes.

[01:15:50] Wes: It it does. It sets the stage. It's just one of those things that you need to be able to show why why interoperability is needed. So

[01:16:02] Dennis: Correct. And it

[01:16:02] Wes: you know, like, if I if if I was in a particular vendor with a particular asset network, why couldn't that just be a vendor specific client? Right? It's like, when when do you have somebody moving from different networks that you wanna be able to use the same interoperable API versus, you know, a vendor specific one for that network? And can you considering each network each asset network, I believe, is, you know, significantly different. It actually may be hard to come up with a standard API for a registry because there's a lot of parameters and things like that or steps to actually register or, you know, whatever. So I'm just spitballing. Right? I don't have a

[01:16:47] Dennis: Yes. No. It's it's it's very relevant. I mean, in Swift, you have this ISO twenty twenty two twenty o 22, you know, protocol that defines the semantics of the messages. So this is something that, you know, Swift came up with because it's impossible to do otherwise. So you need to have, you know, definition of things in a semantic way so you could make sense of what was going on. If you see what's happening now with stable coin transfers over different networks, you can have you know, you see that there are specific protocols that are vendor vendor dependent. So typically, Circle might have, you know, connectors to different networks, but it is their own protocol. So the the important thing here to to to to mention is that we are going in a vendor independent cross chain, cross network transfer. And this is one of the unique things that we do in in SATP. And therefore, we need to have things that are accessible, not necessarily that all may agree, but you know that if you want to have an asset that exists somewhere, you you have to look it up in a in a registry. So maybe the register register things that may not make sense to all, you know, of the the possibilities for transfer because there might be vendor specific things that you put in the registry. But in terms of the general transfer, you you have all the the pieces there, you know, to make sense if this, you know, is something that could you know, if if the transfer is crossing different architectures, legacy systems, networks, etcetera. So we have Peter and Claire here. So

[01:18:28] Thomas: yeah. As

[01:18:30] Peter: an individual, because we also work with some financial alliances in China, I think some cases where you're need registry rather than one to one negotiation, which is the case of alliance. Usually, you have a bunch of people that in that case, they're gonna

[01:18:47] Wes: need

[01:18:47] Peter: standardization anyway. They're gonna need either a some kinda internal agreement or they did gonna be needing some documentation. So those are cases that registry might be needed along along with the end people to avoid, you know, one to one negotiation that explodes in complexity.

[01:19:08] Dennis: Absolutely.

[01:19:10] Wes: Claire, did you want to say something? You're muted if you're talking.

[01:19:24] Claire: Apologies. Thank you. Just speaking from purely from a personal perspective, not chair. Are we running the risk of trying to define assets rather than the protocol itself? Like, feels like this Yeah. Not our core. And, actually, we say that very, very early on that we would assume or or take into an assumption that because this is not a pure this is this is how the asset transfers. Right? But the agreement of the asset would sit outside of the network. That's a that's a commercial or an an offline agreement. So we would have to understand that either the gateways can as part of the gateway requirements, either can transmute the asset or the both underlying networks are capable of of of hosting the asset. Mhmm. And in terms of registering it and and defining requirements for it, I think with with Swift, all of the participants of Swift have agreed various commercial agreements and are aware of what what that that entails. This this is trying to open that up to any participant who may not have agreed to provide x, y, and zed information about their asset or indeed their asset might not have it. This this feels like a bit of a black hole would be my my thoughts as a as a project product person.

[01:20:50] Dennis: Yeah. Okay. So there are there are two two elements in in the answer, I think. One is the the technical aspect of it. So if you want to have a standardized protocol and implement a standardized way of transferring, you need to have somewhere a way to go and access, you know, basic things like the transfer context, the identities of networks, the identity of gateways. So all of that should be somehow standardized. The way that you register things in the registry goes in the direction of standard standardize the the elements that you can put in. So you have a tokenized asset records. I'll I'll show that in in the next slides. So there is a standardized way standardized way of accessing all the all the the artifacts that are necessary for SATP. So definitely, is something that is necessary for processing. Otherwise, we may have very specific individual agreements between gateways. So it will be a lot of things that we delegate to gateways where we could very well standardize standardize because we know the needs of of the SAP protocol. On the other side, like in Swift, for example, you have the protocol for transferring and you have the ISO 20 o 22, which is a standardized way of defining semantics. Here, we're not going in the direction of redefining these things. The only thing we say is that the registry is a place where you can look up in order to understand, if you want, the semantics of this of specific assets. And maybe not be, you know, something. If you know the assets, you just put the the ID of the assets. Not necessarily more semantics because you would like to keep that secret or you would like to keep that in a gateway. That's fine. It's a vendor decision here. The fact is that if you want to have something more explicit about the semantics of the assets, the registry is a place where you can look up and find these things. So if you want, for example, suppose that we have a generalized ISO twenty twenty two that can work for SWIFT, but can also work for cross chain transfers for stable coins that are, you know, USDC, for example, or US stablecoins, or there may be MICA regulated euro stablecoins. So these are all cases where we could say that in a registry, there is a specific thing that called, you know, eventually an asset profile that you can look up and find out what it is. Second thing is that when you have a transfer, you need to name the assets that are going to be transferred. And in the transfer context, you need to have standardized way of defining the the asset identities. So this is also a case where you could specify what the the asset IDs are as part of the context. So there are several ways where you could you know, you need something that instead of delegating all the complexity inside the gateway, you could define a registry. So make it simpler in terms of implementing all the specifics of a pre pre transfer negotiation. So there is some discussion going on. I don't know if there are questions.

[01:24:09] Wes: No. It's all okay. It's just background stuff, so you can go on. So

[01:24:14] Dennis: in terms of now the the content of the the registry, the idea I'm discussing with the group is that there is a standardized way that what we call the recognized artifact record. So, basically, the idea is not in the registry. We don't define redefine the assets. We just have, a smart pointer, if we could say that, with as much semantics as we want that defines the asset that exists in the network. So a tokenized artifact, it is this pointer, if you could say, a standardized pointer, where there are three elements I mean, two elements in it. It's the the data that are verifiable, that capture information about things that are important out there, like, for example, if it is in which network, what access point to the network, what asset type we have on this specific network. And there is also a tokenized version of that in order to make sure that with cryptographic guarantees, we can make sure that the artifact data of the tokenized record are there and are verifiable and immutable. Yes, Peter. I

[01:25:31] Peter: don't know if I get it right. Do you you're kinda want to have some kind of a secure encapsulation or, like, envelope of things. Am I getting it right?

[01:25:44] Dennis: Actually, you can see it like that. It's more than when you have data about the asset that need to be somehow verifiable. You need to you capture them in a tar and you have the tokenized version of them so you could make sure that these artifacts may not be modified. They are there. You have a trace because it's also you have a timestamp with an immutable, you know, append only storage. So you could always refer to the bunch of data or metadata if you want. I would like to avoid that term because it, you know, it complicates things. But it is all verifiable data about the asset.

[01:26:24] Peter: Right. So I Thomas might hate me if I say this. You know, something like maybe JSON Web signature is a way of doing secure encapsulation. But when you say there's you're gonna need some visibility on logs or some additional things, I think those are additional justification that you might be needed to make this, like, a necessity or a problem statement.

[01:26:52] Dennis: Thomas, you want to answer?

[01:26:54] Thomas: Think because of lack of time, Dennis is super summarizing this. So the entire structure actually has two pieces. One is what I would call static information about the asset, basically asset ID and so on. And then there's another part which is a set of pointers. And in some of the discussions, Dennis calls it smart pointers, which tells you, well, which registry is this thing in, Right? And so the whole thing you're right. The whole thing has to be signed JSON or JWTs, whatever it is the group will have to decide. But functionally, one is information. One is actionable thing, which is pointers. Because without the pointers, the code, whether it's legacy code or smart contract code, won't be able to fetch it won't be able to reach out and say, okay. It's in this registry number one. And, no, it's in registry number seven. You know? So so this is where we're we're going at. But to explain this, we need a diagram. A diagram gets very complicated. Dennis will need an hour and a half just to explain this.

[01:28:05] Dennis: But the but going in the direction of what Thomas say. I mean, suppose you get an example of you have a legacy database on one side with, you know, easy numbers. I don't know, you know, whatever definition you have in the financial context. And on the other side, you have a, I don't know, a smart contract, a $79.43 ERC or something. So you have, like, a, you know, a smart contract with specific APIs, and you you have to make the transfer between these two computational elements. So it's super complicated to define, you know, one to one combinations of all these things. If you go to an asset profile, for example, and you say, okay, what I have in my database, in my legacy system, in a core banking system, it is a bond, for example. And I would like to transfer it to a tokenized version inside a private network that runs like a solidity code because it's a EVM machine. For example, this the mapping of these things might be very cumbersome if you do it point to point, but, you know, building it inside the gateway. And the idea here is to say, okay. How much of this we can offload to a registry where you have a standardized definition of what this bond is and say that this bond that you see in this core system access accessible by that API might be eventually, you know, transferred to another computational unit. It's a smart contract inside the private network that is doing, you know, the same thing using an ERC, I don't know, seven twenty one, for example. This mismatching between, you know, the computational units in the different networks and the semantics of it, it's an important, you know, discussion. That's why also in in Swift, you have the 20 o 22 because it makes sense of what the assets are. So here, this is a definition that is a independent vendor independent definition of things that are important for SATP to run. And these are the context, the logs, the definition of the the semantics eventually of the assets. So that's where the, you know, the the the registry is because it you could from the gateway, go there, find out all these things, and have an easier negotiation with gateway too. So as Thomas said, there is a part that in the in the registry that is a tokenized form of the assets. So the TAR token that is there for guaranteeing the the mutability and the integrity and the existence of these things. And there is the artifact part that contains all these pointers to the assets. So there is a cross reference between the off chain and the on chain part eventually. So the the artifact and the attribute part, which is the artifact part. And there is also the tokenized form inside the specific way of could be a ledger, could be an immutable storage. You know, the the implementation is not important here. So the idea is that we are storing things inside the registry. The registry is a way to verify the data. The the attributes of the the artifacts are verifiable because there is a tokenized part. The results always a way to go back to history to make sure that this thing existed in the past. So the registries are somehow the history of what happened in the execution of the various transfer instances. For example, you can go back and find all the transfer context of the past so you can make sure that in case of any dispute after the the transfer, you can go and check what were the the transfer context, what the gateways negotiated, all of that. So here's an example, but this is a very specific way of saying that when implementing it, you could have an off chain, on chain part. There could be part of the registry that is a regular REST API in order to register the task with a simple crude, you know, API. And on the other side, you might have all the cryptographic guarantees that you that are necessary by having tokens of these tokenized asset records that are on chain and that you could look up so you can make sense of everything that you have registered in the in the registries. So just an example. So that's all. Of course, I mean, in twenty minutes, we cannot summarize the the work of the one year and a half in the in stage zero. But I hope that that was an introduction to, you know, the more specifics of what the registration stage zero is.

[01:33:20] Wes: No. That was great. In fact, speaking as your chair, who is not an expert in this realm, everything you guys do is complex. Think both of you mentioned that at some point. And so that was if nothing else, it was very helpful for me to get a better clue of of what you guys are heading for next. So that being said, are there any questions for Dennis or essentially any other business? We are at the end of the agenda. I don't see hands. So I think we will probably call that good. Thank you all for coming. Thank you, Peter, for doing the brunt of all of the work up here that's silently taking notes and doing everything else and maintaining everything. Thank you, Claire, as my remote chair, and we will see you all in San Francisco for those coming in person or virtually if not. Claire?

[01:34:17] Claire: Just to echo, thank you. Thank you for being the in room, in the people. You've done a fantastic job.

[01:34:25] Peter: For presenters, please check the minutes if there is any mistake or needs

[01:34:32] Wes: or people commenting to make sure that Alright. Thank you all.

[01:34:37] Claire: Cheers, everyone. Have a great day.

[01:34:40] Martin: Bye. Thank you. Have a good day day and weekend, everybody.