Session Date/Time: 19 Mar 2026 01:00
This is a verbatim transcript of the SATP working group session from IETF 119.
Wes Hardaker: I think we'll probably start a couple of minutes after just to see if other people roll in. I know this isn't in a harder time zone, as some people were saying, about when the when it got scheduled, but I think it's all the meetings are harder time zones for somebody. So Claire, you can start whenever you feel like as is correct. How's that?
Claire Farrow: That sounds good. Sounds good.
Wes Hardaker: I'm in a meeting room with an 18th-floor view that's going to distract me all day. I apologize for that.
Claire Farrow: Oh, wow. Oh, that'll do. That's lovely.
Wes Hardaker: Yeah. It turns out Tokyo is very, very big, as is Shenzhen.
Claire Farrow: Okay, I think we'll get started then.
Wes Hardaker: Yeah, Claire, your question's good, though. Is Peter in the room? Did he appear or not? No. Okay. So you're welcome to sit up there, but honestly, I doubt we need it, so.
Claire Farrow: Okay, fab. Welcome everyone, especially those of you who've flown over and are online at odd times. I don't think I've got control of slides. Wes, are you okay to click through them?
Wes Hardaker: Uh, yeah, I can do that.
Claire Farrow: Thank you. So, as standard, here's the Note Well. I think we've all seen this. I'll leave it on screen for a couple of minutes. Okay, and there we go. Now I've got the slides control. That's handy. So, yeah, we've all seen it. Thank you. Chair Slides.
Here's a link to the other IETF documents, so processes, procedures, codes of conduct, copyright. I think we're all fairly familiar with them at this point. Obviously, the session is being recorded. I'll ask Peter if he's happy to be our note-taker as our Secretary, Shepard. Sorry.
Wes Hardaker: I don't know if there's a Peter in the room, so. He's remote. I see him logged in, so I'm not sure what happened. I'll start taking notes and see if he pops in.
Claire Farrow: I think he's... I can see him on the chat channel, so he's he's here. Links to the datatracker and about us and what we've been up to. And along with all of our active drafts, I did see the Use Cases one get updated late yesterday, so thank you very much on that one.
So, a bit of an update on where we are. I think to echo Wes from previous calls, we've stormed through the working group to get to the first AD review. So, well done, everyone. I think it was part of our agenda today is to go through that that first AD review and and pick up any actions. We'll come on to the agenda in a moment, but I think it's it's just nice to take a pause and reflect on how far we've come in the short, relatively short time we've been working together. So well done, everyone.
Wes Hardaker: Yeah, one one quick comment about that. So the next steps after, you know, Thomas is going to talk to the changes that were done in a minute, and then our new AD, Andy, is going to probably review it again. Sorry, Andy, you're jumping in, you know, from from the from the cold. So thank you to Ori, who is stepping down off the IESG and has helped us for the last two years, but we greatly appreciate his help over time. And Andy will be shepherding things, and he may review it again and so we're on that point on that line. And then it'll go to Last Call, and that will, as I've mentioned before, give a lot of additional comments, right? You don't get through Last Call without a lot of comments coming back as well. And it's a good thing. It makes the documents better. So and then it'll go to the IESG, which will also produce a lot of comments, right?
Claire Farrow: And yeah, to echo Wes, thank you, Ori, for all of your support over the last couple of years. So on to today's agenda. So introduction, the updates to the SATP core. So thank you, Thomas, for taking the lead on that one. The charter to look forward into the future, obviously with the caveat that we do need to progress to the end of the stages on the previous slide before we can officially start the new charter, if it's accepted. And then a piece on Stage-0 architecture, which is is important context for for this set of working documents, but it does form a part of officially the new stage charter. And then any other business. And then I will hand over to Wes. Thank you very much, Wes.
Wes Hardaker: All right, with that, I think Thomas, you are up. So our agenda for the day will we will go through the the changes that Thomas and others have done to the three core documents, in order to reflect Ori's comments. After that, we'll talk about the charter. It may be... this could be a shorter meeting. Normally we fill all time. I suspect that we won't this time for the first time, possibly ever. And then Thomas will come back and talk about the Stage-0 architecture. As a reminder, the Stage-0 architecture is on our future charter. So we always push, you know, the future items to the back of the meetings because we really do need to progress on the on getting the main documents out the door first. And then Andy will give us feedback for the charter as well as the timing for when he wants to put it in place or if he wants to wait until Last Call for the IETF is totally, totally done. That's sort of up to the IESG to make that decision, but we're headed in the right way. So Thomas, with that, we'll turn it over to you.
Thomas Hardjono: Sure. Should I try sharing slides, or can you drive the slides with...
Wes Hardaker: Either way. I can pass slide control to you too. I have to first turn off slides. Oh, screen share? No, you don't want to do screen share. You want to do the one next to that, slide share. Here, I'll I'll pull them up, and then you... I'll pass you slide control. So you should see buttons appear in a second. Go ahead and start talking.
Thomas Hardjono: Okay, thank you. Updates on the core documents since AD review. Yeah, so just a couple of slides on the architecture updates. Uh, there wasn't much this time because Ori had done a great job, I think way back. Ori, I apologize, I think it was in November, just after the the that IETF. And then following that, there was a longer set of, actually more important comments on Core, which is the actual protocol.
Okay, that wait. Okay. So throughout both documents, we said, you know, TLS 1.2 or TLS 1.3, and I think, you know, we're convinced now we're just going to say TLS 1.3. Let's let's not even like mention 1.2, you know, as an option. Um, it's kind of useful just to say straight up 1.3 because a lot of the readership for this would be a lot of the the financial institutions, banks, and so on, SWIFT and and and, you know, they they just should use the latest thing, which is 1.3.
Um, improved text to explain that Stage-0, what we call colloquially Stage-0, is really the the pre-setup stage. How how do you, you know, figure out if the thing, the asset trying to be transferred is, you know, truly exists and so on and so on. So so added text there.
A good suggestion from Ori was the reading order. So like we didn't we didn't tell the the reader like which document they should read first, so it's like, okay, read architecture first, has all the concepts about two-phase commit and so on and so on before you, you know, go into Core. Because in fact, we did have one guy who started reading Core and like got completely lost and emailed me. And I said, actually, no, you should read the architecture first.
Terminology section has been aligned with the Use Cases, so there's same wording are now identical definitions. It was slightly different, so so that was that was good. That was a good catch.
Next is two-phase commitment. So from the beginning, we started off, if for those who know database transactions, we started off with a a three-phase commit or two-and-a-half phase commit, and it was overkill. So we literally took one arrow out that reduces the the to a true, you know, one-to-one two-phase commit. And however, in the text we kept saying 2PC or 3PC, 2PC or 3PC, so now we just said forget 3PC, we know it's there, we know it can be done with just a single addition of an arrow, but don't confuse the reader. Just say 3PC.
Another thing that that Ori, um, you know, caught and and good thing he insisted. We were using the word "should," "must," and so on kind of loosely in lowercase, you know, the implementation should this, should do that. So now in in many places it's it's capitals. Typos as usual, lots of typos and unclear sentences.
So that's architecture. Now, Core, which is the the more recent set of comments. So this also went through a lot of updates. Again, two-phase commit only, no mention of 3PC. TLS 1.3 throughout. In some places, we had pubkey and public key, so now it just says public key. So for example, the the, you know, variable "originator public key" is now spelled out "public key," not not "pubkey." A few broken references, citations that have been fixed.
Another good addition from Ori was that we had listed things like, you know, time lock, hash lock, hash time lock. These are all um, you know, constructs that a number of ledgers and blockchains use to temporarily disable, you know, tokens or assets on a blockchain. And we were just casually saying these things without any references. And so now for each one of these types, we've added a reference, a uh example at least, one example of a particular ledger system that uses something like this. So the hash- you know, HTLC is used in Ethereum, for example. This is, if people interested, this is section 5.3.15. Lots of typos have also been corrected. Um, so that, yeah. In fact, even even when I was converting it to text from markdown, there were still typos, which is, you know, just as well. But that's all fixed.
Wes, Ori's hand is up. So why don't we let him? Okay, hey Ori, go back. Let me go back to that slide.
Ori Steele: All right. Ori Steele, I guess as your as your responsible AD, but only chairs kind of up to you if you want in-depth kind of back and forth on any of these points. But the public key thing is a thing I I care deeply about, public key representations and that sort of thing. So, uh, if there is time, I kind of would like to to unpack that one a little bit more. Um, up to you.
Wes Hardaker: We have a ton of time today, Ori. So go ahead and hit it.
Ori Steele: Okay. So I think when I read the document, the so first of all, based on my, you know, career experience, uh, I have spent a lot of time converting public keys between different formats, and I've made mistakes doing that. And when I looked at the document, I think the examples that I saw had kind of hexadecimal encoded public keys. And I wasn't sure exactly what the format of those hex blobs was. Uh, and, uh, you know, with with my AD hat on, my my bias would be like which which RFC could define the public key format that you should be using in your document because otherwise why are you making a new public key format in this kind of document? So I wonder if there's a chance to just talk through that piece. And every now and then, it is the case that, you know, you you do need for for backwards compatibility to support uh a non-IETF key format in a protocol. So we we see that. Um, but I don't know if this is one of those cases. That's it.
Thomas Hardjono: No, good take. This was the big one, the big catch. Thank you, Ori. Yeah, we're pretty loose throughout the document saying JSON this, JSON that, but reading Ori's comment, you know, is very clear we had to be very specific. So the the, you know, basically we're going to be using, you know, JSON-related constructs, whether it's JWK or JWA. So Ori, in that example of a public key that's a hex, that was just a random hex. But in reality, it needed to be a key object with curly braces, close curly braces, with the key and the algorithm, and I said, oh God, this is going to be a page-long example. It's going to spill over to page two. So we basically, um, you know, converted it like just hex, and I've added a line at the top, you know, the key object has been replaced by hex for brevity's sakes, but but we know it needed to be the proper key object.
Ori Steele: And you have um cases where you're sort of, you know, hashing these messages. So if you start changing the formats of these things, you you're going to get, you know, there's opportunities for the ordering of members to be different inside of an object in JSON. So it could have a bigger impact as it starts to become, you know, more interoperable and more expressive in terms of key formats. So... sounds like you've already considered it.
Thomas Hardjono: Yeah. And we've added since this this, you know, this topic, we've added a line there saying, you know, when you sign, just to be very, very clear, you've got to serialize it, or some people say canonicalize it, you know, and compress it before you sign it. The usual the usual stuff, but you know, we kind of assumed the reader the reader would know this, but no, we can't like assume the reader knows this. So we've actually put that in there as a line.
Ori Steele: So since you've just mentioned canonicalization, which is another old friend of mine, uh, I did have that question. I think I gave it in a comment on one of the documents about, you know, which for- how are you ensuring that a JSON object will always, uh, you know, hash to the same bytes? Like for signature purposes. I think I mentioned JCS as one option. It's, you know, it's independent stream document, but it does provide a mechanism to do that inside of JSON. Did you did you pick pick one yet, or are you still sort of hoping...
Thomas Hardjono: No, no. So that one we left that, you know, we just did the nice statement saying you've got to you've got to serialize this, you know, remove whatever, remove spaces and whatever before you, you know, sign it.
Ori Steele: Is it a problem if everyone decides to do that differently?
Thomas Hardjono: It's a problem if everybody decides... So could we I would like I would like to pick one. Like can you guys can you guys Ori, can you just tell us which one?
Ori Steele: So um, this this is this is an area where uh you very easily could get into an endless debate going on forever. One of the things in, you know, the JOSE, you know, family that folks do is they sign base64 encoded data as a way of kind of getting around this problem. Um, so that's not canonicalization, it's sort of armoring of the of the payload and then signing the armored version as a way of escaping the fact that you- spaces, tabs, and JSON key member ordering are all variables. That is one approach. You can kind of force it into an armored representation and sign the armored representation. The other app- other approach is to describe a procedure that normalizes JSON, and JCS is one way to do that, but they read the JCS document, there's a whole bunch of gotchas, you know, inside of that. And so I would tend to say, you know, my preference is to do things more like how JOSE handles it when this problem happens. I think how JOSE has handled it for protected headers is a good- is probably my my preference. Um, but your protocol, the way that it's written right now doesn't necessarily lend itself easily to that. So I think this is really a something the working group needs to consider. It's not something that I that I would want to pick for you.
Wes Hardaker: So one of the things that I put when I reviewed it a long time ago, Thomas, is that in all of these cases, if a re- if a reader was not able to communicate with the authors, they picked up the document, could they do something that's interoperable? So, you know, a bunch of those have been fixed in the last year especially. And a lot of times that's, you know, exactly what Ori was spelling out of if you receive a base64 encoded blob, you have no idea what it is. You just know it's encoded, but without some sort of type identifier or something else saying, I'm now going to pass you this type of key in this format, you know, and it's a base64 encoded string of that of that key, is it the public key, is it the private key? Right, all of those types of things have to be done in order for the receiver to be able to intelligently decode it. Um, and um, as I'm not a JOSE expert, so I'll let Ori continue to be the expert there, but um, you know, if if he's right, if you can point to something else that says we're going to do it just like this other RFC, you no longer have the burden of having to do it. But in your document, you still have to say we're going to do it just like that other RFC, otherwise, you know, nobody knows what what's actually being passed.
Thomas Hardjono: Okay. I I think okay, J looks like... Well, Dennis, you've already implemented JCS, so so, you know, you probably have, you know, reasonable experience. And and maybe we can, you know, we can ask Alexandra Alex, you know, what you guys did in in in Quant. Okay, we can take that offline. But thank you, Ori. I think we'll we'll pick one. You know, JCS.
Wes Hardaker: So one final comment, I think Dennis's point of "we use" is is the clarifying notion there that they picked something. Right?
Dennis: Yeah, definitely, we had to.
Thomas Hardjono: Yeah, Dennis had to. Okay, no, good, good. Andy, are you good with JCS? Andy's yeah, please uh...
Andy: I don't care, but Ori did put something very relevant in the chat, that it is going to be a downref and gets called out during Last Call, so just keep that in mind.
Thomas Hardjono: Okay, all right, good. Thanks, Andy. Uh, okay. So so this slide is literally cut and paste from what's in the text, so you'll find this I was pointing out the word "must" is now in capital letters, um, you know, so so very clear and all the relevant references, I think like JWK and so on is is in there. Okay, what's the next... give me one second, as five... is the slide moving? Oh, so so this is interesting. So so, uh, at the end, towards the end, we had this error table and there was an interesting question that made me think for a while, Ori, uh, like okay, how would how would some of these error codes actually occur when you do a run, protocol run? So many of those uh possible errors have to do with the identifier values that has already been peer agreed upon in Stage-0. So a good example is, you know, asset ID 1234 is the one we're talking about, right, the two gateways say. And then if any one of them changes that, you know, suddenly the next message, you know, message uh you know, in the two-phase commit, that ID was replaced, there's a mismatch. So that's an error, and right now if that an error like that occurs, I think the transaction the whole session just gets gets terminated. So, yes, so this is and I and I and that text there, Ori, is what I added at just at the top of that section 13.1, basically explaining, you know, where some of these codes um come from.
Ori Steele: So this this is one thing when I read the document I was really confused why you're sort of why be prescriptive at all about these identifiers in for your protocol? Like they're like you said, they're they need to be agreed upon by both both sides. But isn't that just the case that like as long as both gateways agree that the identifier is- I guess so so you're saying that these error codes exist because at any point in the protocol a gateway might send a malformed in the context of the receiving party's identifier. On purpose? Yeah. So we're allowing for dishonest gateways. This is the other problem is that, you know, these are these are... So we're trying to make it clear that that reduce the room for being dishonest. You're going to get caught, right, just by little switching, you know, IDs here and there, right? Because, you know, I mean you guys hear the news all the time, there's always crazy stuff up you know happening in the crypto space. So you know we work on the assumption that people are going to be just as dishonest now in this new new world of tokenized assets.
Ori Steele: So in in each of these cases, like, you know, there's several messages, each message can contain multiple identifiers, any any one or more of those identifiers could be malformed in a given message that's being transmitted between the parties, and you have error codes for each of the potential places in that message where that identifier might be malformed. And when I read that, I was sort of like, well, why does it matter if one of them is malformed? Don't am I not just rejecting the entire message? Is it meaningful to have, for example, two identifiers in a given message being malformed? Is that important to signal back, uh, you know, other than just reject like why not just, you know, HTTP 400, right? Why have these separate, you know, individual error codes within a given message? That was my my feeling as I read the document.
Thomas Hardjono: Right, right. So we're sort of uh building for the next one of the next features, which is could we do session resumption. So is it possible gateway one sends something malformed and gateway two says, okay, terminate everything? But instead of doing that, gateway two might return an error an honest error message, hey, this identifier is malformed, can you resend? Okay, so provide room. So we're anticipating this feature in the future, which is uh Wes, I don't think crash recovery and session resumption is in not even in the it's not in the recharter proposed text, right? So that's even future future. But we said let's put it there just in case, right? So you want to you want to give room because if uh if you've got all the way, you know, in the flows to the very almost the very end and something goes wrong, like, do we have to restart again from like line one, which is like, you know...
Ori Steele: So it's something for the working group, you know, to consider for this. Like, I would I would try to use something that's out there that has, you know, the affordances that you need in your protocol. One of them is the sp- HTTP Problem Details JSON format, which has been translated to CBOR, but it's kind of a common way of expressing errors, and you might find that there's some useful stuff there. But when I read this, I sort of felt like, well, there's a lot of text about errors in here, and I'm not sure what I would do as an implementer if I got any of these individual messages. So that's that's my that's my comment.
Thomas Hardjono: Right now it's like drop session literally. That's all they that's all they can do, right? There's no- there's no- like what's the- there's no second chance. So this is anticipating a possible sort of second chance of retransmission.
Wes Hardaker: So taking off my chair hat and putting on my operator hat, uh, Ori in particular, I I always like more error messages. So when I get, you know, some HTTP error code that's like 404 and I have no clue why it became a 404, that drives me nuts. And also from a coding point of view, if I can get a a, you know, unique identifier specifier that says this is the error that I got that, you know, clearly explains why, a lot of times with an additional blob of text with supplemental detail, that allows me to debug sort of the situations a lot. Um, you know, we actually recently, I you know one of my recent RFCs is actually doing that on the DNS side. And we went from, I think starting the draft with like four additional error codes to ended up with 27 or something as the working group got through the process of all of the corner cases. And that turned out to be a fairly popular uh document because it really gives the operators the context in their logs of this is what went wrong so that when you need to go back and figure it out. And I would say for financial transactions, that's probably even more important. But uh, so with that, Andy?
Andy: Yeah, so um, obviously, I don't I don't understand this protocol, so I'm not as familiar as Ori, even though I did read his his comments. Um, the but this whole thing about the and Wes I agree with you, more error description is usually better. Um, but if this is uh being used over HTTP and you're uh doing things like uh I'm returning 200 but really it's really an error or something like that, then you're going to run into issues with BCP 56 alignment. So I would I would suggest running through BCP 56 and making sure you're aligned there.
Thomas Hardjono: Okay, no, that's good input, yeah. Didn't think of that, you going through. Okay, let's let's do that. Yep. Okay. Okay, uh any other questions? Let me go next. That's it, last just huge thank you to Ori. Ori, now that you're now that you're free, you can you can help us write some drafts.
Ori Steele: I'm grateful that you think I'm a security AD, but I'm an applications and real-time area director. And if the security ADs see this, they're going to be unhappy, so...
Thomas Hardjono: Okay, I I'm sorry to have demoted you. Sorry, I- I appreciate application AD.
Wes Hardaker: Well, the confusion stems from Paul, who was the previously assigned AD, was actually a security AD, so we have shifted from- but we're in the apps area, so yeah. All right, all right. Any any other questions? Okay, uh I will stop sharing, or do you want to take control back?
Wes Hardaker: You can go ahead and stop sharing. Stop slides. Okay. Okay. Let me... So um, going back to the chair slides. Chair Slides. The very the next item in the agenda was the charter discussion. Um, we have gone over it extensively. Last time we actually went through paragraph by paragraph and, you know, thought about it as well as, you know, came up with the list of uh of next goals that, you know, that we should do and narrowed it down to five or six or whatever the the current count is. Um, since that time I took the previous charter, rewrote it a lot, and then Claire took it and actually made it readable. Uh, she greatly improved the wording and a bunch of other semantics and things, uh, as well as added some uh additional background and goals and things like that. So it's fairly lengthy right now. It's probably a little bit longer than average charters, and the IESG, of course, will give us feedback on that as well. And uh Andy's already promised me that he'll he'll review it in the some time in the near future too. In result, I did not make a slide deck with each paragraph on it because I think we're beyond that. I sent it to the mailing list yesterday, uh meant to send it earlier in the week, sorry about that. Um, and this is just a time slot where, you know, people that have read it can, you know, comment on whether they uh have issues with it or things that that don't look good if you have managed to read it in the last um 24 hours or so. So with that, um since I suspect some people are staring at their laptops looking at it, uh we'll give a a slight pause, but if anybody wants to bring up comments on the charter or thinks it looks bad or good or have suggestions, now's the time. But we'll pause here until uh it feels like there's enough time.
All right, I am not seeing any hands, and I'm getting a lot of comments in the chat saying that it's uh looks good. Uh, um, so I think with that, Andy, we'll we'll it's probably on your plate now to take a look at it, okay?
Andy: Uh yeah, um, the I need to figure out where this fits into like um I need to figure out the priority for this. I think that's what I'm trying to say. The uh the because the I think if we go for a recharter now without the documents actually in the current set of documents in uh uh they're not even in are they in pubrec? What's what's the status? They're pubrec? Sorry, go ahead. Okay. Yeah. So so, um without them without them having gone to uh a ballot, I think uh I'm going to get some pushback. So we we may have to wait there.
Wes Hardaker: No, that's that's fine, and I uh I should fill you in on the status which is, you know, the the documents have gone through multiple reviews internally, it's gone through working group last call, it's now gone through AD review, has been sent back with a revision needed, is the current state of the three documents. Um, and then Thomas just talked about, you know, what the changes he made to um to reflect Ori's comments. Um, I would argue you actually, you know, absolutely have the right to think and review them all as well and, you know, provide additional comments. But in the long run, you know, yes, they should get to IETF Last Call and all through that process. When the IESG wants to consider a recharter because they think that the these documents are, you know, far enough along that a recharter is the right time, the timing's up to you guys, so.
Andy: Yeah, um, I will say as I did I I don't remember what I said much much about it, but I did read Ori's comments. Um, just because I have to keep him honest, but the uh I do think there was just as a heads up, there was one document that had a bunch of common names or something in there, um or names of companies or something, and I'm probably going to be insistent that those that those get changed to example names or something like that.
Wes Hardaker: Uh yeah, I would agree. Uh surprised I didn't catch those if you did. So so we can always put it in an appendix and have the RFC editor remove it if if there's implementation examples or something, but yes, I agree.
Andy: Yeah, as I recall, it was the name the names of two companies Verisign and GoDaddy. So but could have been something else too.
Wes Hardaker: I'm sure Thomas is somewhere nodding his head right now, so it's all good.
Thomas Hardjono: Okay, it's probably the Use Cases because I think the the example text is all example.com or gateway1 gateway2. I think in fact we used to use like Quant.gateway1 and then we we took out Quant.
Wes Hardaker: Yeah, and I think Ram- Ram has got his hand up remotely. Sorry, first in queue, as the author of that doc.
Rama: Yeah, uh thanks. So I did take a look at Ori's comments and unfortunately, I couldn't get time to fix them until yesterday. Uh, the specific comment was about not using an example uh alice.com. So he suggested I should use alice.example instead, so I changed that. Yeah, it's it's updated now.
Andy: Yeah, and that kind of thing is a that that's a that's a well uh we have a lot of um very well-understood uh examples for that type of thing, but uh what is not usually clearly spelled out is you can't use common names unless there's a really good reason for doing it, right? So um we kind of shy away from doing that.
Wes Hardaker: Yeah, and for those less familiar with the IETF process, the use of .example at the end of a DNS name or example.com are both accepted, they're documented as example, you know, domain names that we can use. And I should have caught that being a DNS geek, but...
Ori Steele: So just just to clarify on the- Andy keeps using the term, you know, common name, and I think this had yeah, it probably was in the Use Cases document, but since I read them all at the same time, they're all blending together to me in my mind right now. But but the um main thing I wanted to point out here is there was sort of a use case in here that looked like it would kind of overlap with or directly connect to the Registrations Extension working group. It was like EPP was mentioned in it, and so the the main point of that AD evaluation feedback was: have you talked to the Registrations Extensions group? Have you asked the chairs to, you know, share the document and the framing around, you know, the language that you have about EPP in that group? Um, and that is the specific text that mentions uh you know Verisign and GoDaddy as I recall. So um, it's just, you know, when you're in your working group talking about a protocol that's maintained by another IETF working group, it's always good to to ask the your chairs of both groups, "Hey, take a look at this," you know, maybe have the working group coordinate feedback around that topic. That's it.
Andy: Yeah, and I just wanted to say, I kept saying a common name, I meant proper name. Uh the when I specifically talking about is like we had a unrelated to this, but we had a a document come through the IESG and it um named a pop star as just an example in something that was describing uh music or something like that. And it was like everyone was like, "Oh, that's pretty cool," but the you can't do that. So um or you shouldn't do that.
Wes Hardaker: Okay, thank you. So we've wandered away from charter discussion, but that's okay. Um, I'm actually a close colleague of the chair of RegExt, so I will talk to him specifically, like asking him look at the use case document from that point of view. That's a really good point, by the way, of uh other groups may want to review that um if it closely aligned with another use case. Uh one additional point for the uh charter, as uh yesterday in the SPICE working group, which is not something I normally normally follow, but I happened to be in there yesterday to uh be the Google employee sitting in the Google office that we had to have somebody assigned to there. Um somebody actually talked about bill of lading related um drafts that they were looking into how to encode those. And then, you know, that was a very early discussion in the start of SATP for um similar, you know, future work items. And then it was also mentioned that it's going to be discussed at um SKITT, thank you, SKITT and SPICE. Thank you. I am at the end of uh 15, 16, 17 days of travel, and my brain has decided to turn off this morning, so I apologize. I hit a wall sometime about 7:00 AM this morning. Um, so thank you, all. Anyway, so um those might want to go look at it, that's my only point. Um, it's not in our charter at the moment, um but I know that there's working group members of that have high interest in that particular category. So with that, last call for charter discussions and items.
Hearing none, then I think Thomas, we will go to you now for Stage-0 considerations.
Thomas Hardjono: Okay. Oh, and then slides get requests. SATP Stage-0 Architecture. Yep. Slide. Yes. And then you get to pick the slide deck. Oh, okay, so it's Stage-0. Okay. Sorry, I didn't realize that's pretty fancy you can choose slides. Okay.
Uh, so so so this is just a report in to the group, um several of us several members of the group have been talking about this for at least, you know, six months, maybe nine months, you know, what we call Stage-0. So for those who, you know, new to the SATP working group, uh our stages was like Stage 1 was, you know, prep, Stage 2 was, you know, locking asset locking, and Stage 3 is, you know, the two-phase commit confirmation. So it's Stage 1, 2, 3, so we've been saying Stage-0 basically for the setup stage. So I think going forward, we might have to call it something you know better like, you know, setup setup phase.
So, uh, in, you know, in discussing all of this, we're trying to sort out the different sub-areas, and there's at least three if not more. So I'm just going to list three and describe, you know, briefly what they mean and what they apply to. So so the big one here uh is uh what what we call the pre-transfer context establishment. So uh before SATP core actually runs, the scenario, the most common scenario, I think in our minds is that here's a user Alice on an application uh agreeing with user Bob on application 2 saying, "I'm going to transfer to you, Bob, um this particular asset," tokenized call it a tokenized asset in this in this particular network, and there's an asset ID and so on and so on. And so these two applications need to establish out-of-band some kind of uh identifier uh and contextual information that's relevant, and then each of these will have to uh communicate this choices to the gateways. And then the gateways will as as the operators of the gateway will will of course want to verify identities, you know, Alice's identity, Bob's identity, and of course, you know, whether the the tokenized asset truly exists and it, you know, and so on and so on. So that's kind of the setup, and so that's what we mean by context establishment.
And so this is problem area one, there's a couple of slides on this. Problem area two is if you're an asset issuer, you're a, you know, bond issuer, you're the the DTCC in New York, or you're Franklin Templeton that's just wanting to do tokenized bonds, or you're Goldman Sachs that's, you know, actually it's Morgan Stanley who wants to like issue their own their own, you know, tokenized uh securities, uh they it's pretty straightforward to do this today on on, you know, several blockchains. That's not the problem. The problem is uh where do we find the information that backs up this claim saying that this is a truly legitimate asset, regulated asset within a particular jurisdictions like the United States or the European Union or some other country. So that's problem two. Problem three and and we we talk about artifacts registry, and this is interesting because somebody I think Wes you just mentioned SKITT, so this this you'll see this is very reminiscent of the SKITT problem, the set of things that SKITT, you know, uh is solving. Number three is so I'm I'm the gateway, I've received this context, um or I'm Bob, I'm Bob's app, and like Alice has sent me this information, this token. Where do I find out uh you know where this all this information resides? All the off-chain stuff, all the legal stuff, all the- where do we do that, and how do you how do you access it? So that's problem set three.
So okay, so let me just do quickly one. So so this is roughly the the, you know, setup stage protocol between uh actually application one, gateway one, application two, and gateway two. So this is kind of what it looks like. But uh and ignore all the details, this is still sketch. The important thing that's different from the previous flow in SATP Core is that now we've got this thing in the middle, which we call the artifacts registry for lack of a better name. If people have a better name than a registry, we're quite open to that. The idea being that this is a place where the concerned parties can go and check something, or can fetch data to to do some checking. Right, so um how do we do that? So that's that's kind of what it is.
And um so um you know, several- and and the purpose is I think before you even start Core is to at the very least to verify the correctness of some of this information. So if Alice says, "Oh, I've got an tokenized asset in network one, here's the identifier," you know, um did did Alice choose the right, you know, was there any error in that choice? Was it the real choice? Did did Alice try to lie? You know, all that stuff. Verification of identity of actors. So in the realm of regulated assets, at least United States, actually even globally, um there are some identity KYC-AML requirements that needs to be fulfilled. So um actors, including gateway operators, they're under obligation to check the identity of the actors, check the identity of Alice, check the identity of Bob. Is it a real identity, is it a fake identity, and so on and so on. So that's, you know, part of this process. And uh if you go to the documents section of SATP, you'll see a proposal from Ned Smith on using a thing called a V-LEI. For those who don't know, LEI is the Legal Entity Identifier, which most corporations in the world have today. It's it's a- it's a- it's like a string number but it's like a string only. V-LEI wraps a whole bunch of stuff around it, including keys and so on and so on. Um, then verification step is um how do you update, if you're the issuer and you're issuing a particular tokenized asset based on some kind of uh what we call profile. Call it a template, you know, uh we call profile, and then you update the the template file itself, like what happens? Do you have to like update the registry where all this metadata resides, right? So this is again big problem, maybe it's some of this stuff is out of scope. Right now we're just throwing that in so that it's clear that we're thinking about it and maybe SATP's not the place to do it, maybe the IETF is not the place to do it, maybe some other organization such as ISO could do it, or, you know, a network such as the SWIFT community could address the problem.
Okay, so this is kind of, you know, the the, um sorry, LEIs do not cover most corporations. Thank thank you, Ori. Ori is is better is better informed than I am. I just assume everybody's got an LEI, but, you know, that's just me, you know, living in a bubble called Boston, you know, so there you go. And Boston is a bubble, folks, believe me. Um, so so this is kind of a rough sketch of what we're talking about. So we're using the European Union definition of of a reference token. So so if you read the MiCA regulation, Markets in Crypto-Assets, you know, back in 2013, they split the road is this fork at the road. One token is uh they call electronic money token, basically currencies such as stable coins like USDC and so on that, you know, um is is being you know available today. And the second one, which is the challenge, is here's the token uh on the on-chain, on a ledger, but the token has a whole bunch of pointers, whatever the pointers mean, maybe it's a URI, URL, to something that's off-chain. The idea being that the ownership of the asset off-chain is signified by you controlling the token off- on-chain using your public key. Right, but but the token itself is not the value, unlike currency tokens. It's it's just a ownership proof. Right, and so we've split this into two. There's there's the value part and then there's the data part. And we're concerned about the data part, because without the right pointers and ways to look for look for the data, explore discover the data and verify it, uh no recipient, no gateway is going to want to you know handle this. Right, and this is part of the part of the setup stage.
Um, so this is what it looks like. And so the idea is, here's the issuer, it, you know, downloads a whole bunch of metadata into an registry somewhere. We don't know where. Uh it's an append-only registry, we think. We think it needs to be persistent, i.e., like 50-year persistent type thing. And then the issuer mints this token on this asset network one, NW1. It's got these two parts. And then the gateway's got instructions from Alice, "Oh, transfer this token that I own to Bob in network 2." So gateway one reads, he has access, it has access, it has access to the ledger, reads the token first before it does anything and says, "Okay, here's two parts: the data part and the value part. I'm going to look at the data part and verify all the pointers before I even do anything, and, you know, in, you know, even before I I, you know, do the SATP Core." Right, so this is that's why it's yellow. And that's what, um, you know, this whole discussion about registry is concerned about, a large part of Stage-0 is about verifying the data part, the the yellow bit.
Next slide. And so why is this relevant? Um, and you know, Dennis is probably the best person to explain this, but but and we've been using this this structure called the tokenized asset record to talk about that yellow part. It's basically making a utility token- a utility means has no monetary value, it's it's just a it's just a data token. Uh, but but how we what we put in this data token and how we process it has implications on how we design uh you know the registry. What do we want as requirements from the registry? Is it, you know, beyond the obvious things like append-only and persistence? What else, you know, what does the API look like, how, you know, do we need access control over it? Could we use something like SKITT, which is the basic transparency service that's appending stuff, you know, it's been signed by a notary to an append-only ledger? Right, so this is why you think why is Thomas going on about this this token, this data part? Because it has, you know, implications to the design of the registries, or at least what we'll be demanding in terms of, you know, requirements.
Um, and this is again related, right? So and anyone's got questions, feel free to to jump in. This is a sketch, no solutions offered, just trying to understand the problem, you know, areas. And so if I was a an issuer, I was Morgan Stanley, Goldman Sachs, which registry do I choose if there are there are multiple? Is it asset class dependent? Do I say, "Well, you know, for bonds you have to use this ledger system because that's what the bonds industry in London sort of is using"? If it's, you know, I don't know, tokenized real estate, "Oh, maybe it has to be this ledger." Why? Because the big, you know, real estate players, you know, developers in this world use that particular ledger. Right, so that's, you know, first question. Um, another interesting one is that if indeed the token has the value- the asset has a data part attached to it in SATP Core, when we transfer the token using Core, does it mean the data part also gets copied over with the value token to network 2? Right, so this you probably the immediate answer would be, "Yes, we we'd need to do that anyway," right? So this is a question we need to clarify. Are there any implications to this, right? So if in SATP Core, gateway 2 is supposed to be reminting this token, what if gateway 2 is slightly dishonest and and changes the contents of, you know, data the data fields, some of the data fields? Okay, this is a for later discussion.
Interesting other question. If then some artifact information uh in a registry uh is is updated by the community, say there's a bonds community, you know, in London with all the bond traders and industry, and they use a template as I said before, and they modify the template or there's some new regulation coming in that that necessitates a new field being added into the template and therefore to all future, you know, tokens, how how do they update the registry? And what if what if the registry has copies, propagating copies, do we have to like manage all these copies? Right, so now Ned Smith suggested, "Well, you know, something-" as usual, we don't want to invent stuff, we want to reuse what is in the IETF or what already exists in industry. Could we use something like the pub-sub model? So, you know, the issuer, you know, does an update and a whole bunch of, you know, parties are sort of waiting to get notification, right, things like that. Um, another one: um, if we're going to use something like LEI, V-LEI, some kind of of, you know, verifiable credentials and so on, does that get stored in a registry, the artifact registry? Right, I'm being careful when I say registry because people think, "Oh, you're talking about the DNS." I said, "No, no, we're not talking about the DNS, we're talking about an artifacts registry." Lots more question questions that that we need to answer as part of the discussion. Uh, I think I think that is it. Okay, sorry, I haven't been reading the chat by the way. So if if you guys have any questions, um please feel free to put up your hands.
Wes Hardaker: Uh, Ori, go ahead.
Ori Steele: So you said it at the end, you know, we're not talking about the DNS. Like, but why aren't you talking about the DNS? It sounds like you're trying to publish a bunch of information. Um, there's been a lot of presentations, you know, at this IETF about storing various things in the DNS and naming things with the DNS. And it seems to me that you're naming things that you need to send updates about when they change, and the DNS would work fine for some of these use cases, potentially. Like, much better than more complicated things that aren't, you know, necessarily well-defined by the IETF. So why is it that this discovery of changes to an asset isn't the same problem of discovery of changes to an agent configuration that's named by the DNS?
Thomas Hardjono: Right. No, that's a good... for for detecting changes, yes, we could use the DNS uh but but but but the artifact itself, the registry needs to be append-only and persistent 50 years. Meaning that that's why I mentioned SKITT, you know, being having more permanence than DNS because you could always reconfigure the DNS, right, remove records and so on.
Ori Steele: I I don't I'm not sure that that problem needs to be solved by your this group. You guys are building gateways where you often assume some structure of the network uh and also security properties of the networks behind the scenes. And those security- each of those value networks have different security properties, and we could talk about how some of them are safer for certain security threats and others are safer for a different set of security threats. So I'm not sure that you need necessarily to have any of that here. And then also, you know, in the protocol that goes back and forth, you know, you're you're committing to structures along the way. So I yeah, I guess, you know, it doesn't seem it seems to me like you, you know, first of all, you you might not need to pull in all of SKITT to this use case. And then second, like if this is a naming and discovery of updates regarding a name thing, like that is a problem that's sort of pretty well-solved for within the IETF already. Anyway, that's all these comments are as an individual.
Thomas Hardjono: Yeah, no, no, thank you. So the last bit is is yeah, yeah, yeah, we don't- so we don't want to reinvent the the pub-sub, you know, model. So yeah, anything we could use, I think we we want to use. And for the registry, you know, Ori, we might end up specifying requirements. It has to be it has to have this, this, this, and this feature. And so somebody wants to stand up a service a artifact registry service that satisfies those requirements, you know, running your database, depend on your database, fine. They want to use a hashgraph, fine. Some people might want to use IPFS, for those who don't know what IPFS is, right? Say, "Okay, you know, so long as you can you can, you've provide these, you know, these guarantees, you know, persistence and so on and so on, then it's good." The reason why I talk about persistence is that the financial industry persists stuff. I mean, I've I've told there are documents that are like 60 years old and 70 years old that are still live, you know, as a form of securities, as a form of asset, right? So that's, you know, that kind of gives you an indication that for digitized or digital assets, the industry may want persistence going out 50 years, probably even longer.
Wes Hardaker: So also as an individual, um and an individual with a lot of DNS background, um and and knowing the um at least knowing at a high level the the SAT architecture, I would think that what so if you want to put something in the DNS, it's really the gateway discovery mechanism. So that you knowing you need to talk to a network um a SAT network that is registered under example.com, um, you know, you could search for something like under bar SATP.example.com, which is a common way of, you know, we do stuff in the DNS these days, that would get you to the gateway. So you know how to contact the gateway, possibly using a DANE key as something as Ned put into the into the comment, of knowing how to how to trust that you got to the right place. And then you really need because the the gateway is going to be able to communicate the assets behind it, right? You don't want to put all the assets into into the DNS, that would be too much. Although people do that kind of thing, don't get me wrong. Um, you know, it seems better and especially from like a pub-sub type of model than after that to say, "I'm you know, please uh connect to the gateway, uh give me your current set of available assets that you're able to transfer, whatever that might be, and also let me subscribe because I know you're about to publish a bunch more and I want to be the first person to bid on it," or, you know, whatever you can imagine all those types of cases. That seems to me like a much more efficient way to do stuff, so you end up building a network of gateways that are, you know, connected based on the DNS lookup records for how to contact each other or something like that. Um, you're building a world that's going to take decades to roll out. Yeah, yeah, yeah. But with that... I apologize, I don't know what ATP is. Is that a new working group?
Andy: That is the that is the that is the protocol that is being used in BlueSky and uh so Andy looked like you actually know the answer. That was being talked coming to the IETF. I haven't heard that it actually did. No, no, no. We just assigned two co-chairs, so they the announcement is in uh hasn't gone out yet, but it should go out day- in a couple of days.
Wes Hardaker: Awesome. Okay. So Dennis.
Dennis: Yes. Um, yeah, couple of comments here. Okay, the the 50-year persistence, it's okay, it's something that is probably related what Thomas said about the the profiles and all the the history of what the definition of the assets are because the transfers within gateway would be something that has a definite and short-lived time until the the transfer is completed. So indeed, we don't need, you know, such a long period for proofs of logs for or any other thing related to the consistency of the transfer protocol transfer in SATP. Uh, so the main thing about what we're discussing here in the setup stage is first of all to have sort of persistency mechanism that is outside the networks that might allow to have more semantics integration of the different transfer of assets, because you, you know, every network might have a different way of representing assets. And this is different from the notification mechanism that is definitely necessary everywhere in in SATP because also the state of the transfers, the fact that the gateways might have completed, you know, all the notifications that during the protocol might be necessary for liveness and safety reasons. So all of that are things and mechanisms would be needed to notify. So the discovery also of asset profiles and and things like that is also something that requires notifications. So the pub-sub mechanism to me it's it's an orthogonal thing. It's different from the storage that we're discussing here about registries.
Thomas Hardjono: Yep. No, thank you. Thank you, Dennis, yeah. And thank you, Ori, for the who posted the ATP. So that's it. Ori, thank you, yeah, that's interesting. I think I think if we could use ATP, we'd just use ATP. We don't want to reinvent ATP.
Wes Hardaker: Yep. All right. So with that, I don't see any more hands. Is there anybody else that has comments or questions for Thomas on at least this preliminary thoughts of Stage-0? Also referred to as somebody pointed out the setup stage or something like that in the existing documents. Okay, Thomas, I think if that's the case, um I don't see any more hands, so I think that we're good. And that actually brings us to any other business. Is there anybody else that has things they want to bring up for the day before we close?
Ori Steele: If if we had time, I wanted to come back as an individual for all of this. Um to the schema registry sort of topic. Um because I have seen this kind of show up in a bunch of different places around um, you know, a protocol has a whole bunch of types, they want to make sure everyone agrees on what those types look like within that protocol. Um and so if this sort of the shape of the asset problem um could be kind of very very well-crystallized, and I've seen shadows of it in the documents that I've reviewed from this group. Um, that that seems like a thing where um before SATP sort of finally finishes thinking about that, um if there is an opportunity to make sure that there's some alignment around this schema registry topic, I think it could be- could be worth just a little bit of coordination with other groups around it. Um, that's that's my my thought.
Wes Hardaker: No, that's a very good point. I mean, one of the things that I have been concerned about is uh that we keep coming back into centralized versus decentralized kind of, you know, scenarios where everybody wants to make their own registry and things like that, and that was actually heavily discussed this week in uh the decentralized uh research group, actually, and that might be one of the other places, Ori, that uh we I would encourage the existing participants to go look at because they're trying to solve that kind of thing. And interestingly enough, everything keeps falling back to the DNS because at some point you need a registry. Um, but all right, Dennis.
Dennis: Yes, I don't know if I can we can see the slides that I, you know, shared before just to show one or two things following up what Ori was also mentioning. Um, I should have a way to control the slides. One, yeah. Okay, so yeah, related to the registry, there is one comment in in Core- I mean one picture in Core, showing the API-1, API-2, and 3. And so here's a picture of how the the registries might get into the mix uh with the network and the gateway. So here's about something that is a standardized way of storing things that are artifacts as Thomas said that are necessary in order to be able to have the client and the gateway communicating about the whatever is necessary to share. And specifically for the setup stage. So the thing that is um interesting and important here is the fact that we're having assets that are eventually tokenized and they are transferred. So we have not only the case of real-world assets that are offline, but definitely we are in an environment where the the networks have some sort of digitized version of the asset. And the whole point here is about making sure that when we go over these, you know, systems and components, we can have some way of proving that uh some assets exist, and even more so and giving some hints about the semantics of things. That's where the the asset profiles or schemas come in. And it's also the fact that because we are talking about uh networks that are definitely DLT-kind of networks, there's this notion of having the consistency between off-chain and on-chain uh information. So that's where this notion of tokenized assets come, and the idea of the the registry is that um we need to cover the uh the flow of information between existing networks, gateways, and also remote networks and gateways. So that's where the registry comes in, so we could have some sort of tokenized asset record as Thomas explained that maintains the consistency among all these uh these components. And the the the artifact registry is the place where we could store this tokenized uh form, the the data part as Thomas explained. So that's the main idea of having the uh the asset registries uh on one side to negotiate the setup stage with the gateways and on the other side to maintain some sort of consistency definition of assets um that is important uh when you do transfers especially when you have different jurisdictions and you have, you know, uh constraints about the the way that the assets are transferred. So that's in a nutshell a few things, maybe a different point of view, I mean, different way of, you know, presenting things as complementing what Thomas was explaining before. So...
Wes Hardaker: No, thank you for that. I think it's helpful. Anybody have comments for Dennis? All right, I see none. So that brings us back to any other other business. Anybody else have things they want to bring up for the day before we close?
All right, I don't see anything. So thank you all for coming. Thank you, Peter, for taking notes and manning the front desk for us. I hope to see a bunch of you in Vienna, and uh which is coming up quickly, as they always do, um June, I think, July, somewhere in there. And uh we will meet again. Um my guess is we may or may not have an interim, um so if you're interested in an interim, please do write to the mailing list and let us know topics that you might want to address, and Claire and I would be more than happy to um set one up and hopefully it'll be a better time zone for Claire next time, so.
Claire Farrow: Great, appreciate everyone's inputs today. Thank you very much.
Wes Hardaker: Okay. Thanks all. Bye.