Session Date/Time: 21 Jul 2026 14:30
[00:00:06] Marco Davids: Say again? It's suboptimal.
[00:00:20] Pavel Kovářík: Marco, can you hear me?
[00:00:22] Marco Davids: Yes, Pavel. We can hear you loud and clear. Thanks.
[00:00:24] Pavel Kovářík: Okay.
[00:00:30] Marco Davids: Raul, can you say oh, Gavin, can you speak again, please, for some testing?
[00:00:34] Charles Eckel / Max Gerber: Hi. Can you hear me?
[00:00:35] Gavin Brown: This is Gavin.
[00:00:36] Marco Davids: Yes. Now you're loud and clear. Thank you. Alright. Let's, let's start. So, good afternoon, everyone, and, welcome, especially the last guy entering our new area director, Charles. Hello.
[00:00:57] Charles Eckel / Max Gerber: Hello. Sorry. I'm late.
[00:00:59] Marco Davids: Nice to meet you. Welcome, everyone, at the, RPP working group session of IETF 120. My name is Marco, and online on the screen, we see Gavin. We are the two co chairs for today of this working group session. Before we start, let me show you the note well. It's a reminder about the processes and policies that you have agreed to follow when you participate in the IETF. So you already basically signed up for this when you registered for this meeting. But please read it carefully. You're also encouraged to read the source documents to which this, note well, refers. And if you have any questions or concerns, please feel free to contact the, chairs or the area directors. These are the usual meeting tips and some resources. I'd like to point you to the, one at the bottom, which is our GitHub page. This is the place where we prepare meetings and where active documents are being maintained. So please make yourself aware of that and have a look at it if you if you will. This is the agenda for today. We're now in the first part. I will give you a brief status update about the current work and the current status of documents. Then we will move on to working group business. We have a couple of presentations. Actually, we have a pretty full agenda, which is also why I would like to request to the presenters to keep an eye on the clock. It's important to give everybody a chance to say whatever they want to say, and also leave some room for questions and discussions. So we will be presenting, about the deliverables and about some new work as well. And then when time permits, Martin also wants to collect some feedback about two drafts that he that he and Matt, Powell are working on, which are about OAuth transfers and OAuth delegations. And then after the afterwards, all the way at the end, Martin also plans to give a hackathon update. So, we had a nice bunch of people working on RPP over the weekend, and Martin will give us a recap of that. About the current status of documents, Gavin and I defined a couple of milestones in conjunction with this working group at the beginning of this working group, and, we also set a couple of deadlines to that. If we go through them, we will see the requirements documents that has now been finalized. It's not being published at the moment. The idea is to put it on hold and then focus on the remaining work. And then after that, we can go back to the requirements documents, see if it needs an update or a a modification, and then perhaps publish it after all at the end. So the current status is a parked status. It's part a parked document at the moment. We have the core architecture document. It's an active document, but at the moment, there is more focus on the on the other work. But it is still there, and I even saw that Powell has kept it alive before this meeting. Then between the previous ITF and this one, three more documents were adopted by this working group, and there will be presentations about the that work, during this session. And last but not least, we have, a milestone which we called mapping between RPP and EPP. There's a little question mark there. We we must try and figure out where that fits in, but Gavin and I will will will look at that, and we will get back to that when when needed. With regards to the deadlines, well, the first two were met. With regard to the other deadlines. They may have been a little bit too optimistic, and we are considering to have a closer look at that. And we'll get back to that if there's any news to report on that. And then I have Powell in the queue. Do you have a remark, feedback?
[00:05:15] Pavel Kovářík: Just a remark about the architecture draft. So let's say we are still referring to the architecture when working to the on the other drafts, but so far, there was no need to to make any any updates to it. I just wanted to remark to make a remark, but this document didn't get through any, like, a working group last call like we did for the requirements. So this may be a question to the to the sales to the the group if you want to spend our cycles on it, or we just focus on other documents.
[00:05:51] Marco Davids: Alright. One final remark while you were speaking, Paul, I realized I didn't mention the notetaker question. That's because we already found two volunteers. But if you want to make notes as well, you know the place to find it and feel free to to add whatever you want to add, but please also then add your name to the notes, if you will. I suppose that brings us to the first presenters of today. And I see the slide deck is shared by Gavin, which is cool. And that would be Pavel presenting about the RPP data objects document, and you have fifteen minutes for that, Pavel.
[00:06:32] Pavel Kovářík: Right. Do I do the clicking myself, or do you give me control?
[00:06:37] Marco Davids: Whichever you prefer.
[00:06:38] Pavel Kovářík: That's you can read to me. Yes.
[00:06:41] Marco Davids: Give you the slide control. Alright. There you go.
[00:06:47] Pavel Kovářík: Alright. So there's the the updates to the data objects draft that we we've made in, let's say, the current iteration. So, again, the reminder where we are in the in the architectures, we are talking about data elements and the and the operations within the resource definition. So we are not talking about representation in this draft. So the we are actually two updates to the document in between. So there was still the the before the adoption, there was the update to the postal info, but this was more or less a clarification of the the data type and some editorial changes. And this version was adopted. And then in the zero one version of the adopted draft, we added, let's say, the data objects which are related to organization, organization role, user objects based on RFC 8543. So this kind of implementation of the requirements about including this this objects that we put, let's say, in their current document. And at this point in time, we consider that we have all provisioning object types in the draft covered. They might not yet be, let's say, completely final, but at least we have we have the the completeness from from the side of the object types. We made some structural changes in the in the way that we or or additional properties for how we describe the the objects. So we added unique identifier elements. So, basically, we we say clearly which element is the unique identifier. We added a flag saying that the objects is has a direct access. This kind of allows us to define in the call draft how such SAP resources are expressed in the URLs. So so I think Martin will will refer to this more in the course draft update. We also are saying now that the old properties beginning with at our kind of forbidden and the the data objects. And, basically, because we make use of this kind of special character in the in the JSON representation. So, basically, we don't want to to have an ambiguity in this field. And I think this one is one very, very significant change that we we did on our addition, but we added a notion of external data types, which allows us to incorporate JS contact. I think I will have a slide about exactly this change. So, basically, including of of JS contact was also one of the requirements that we should at least attempt to to to use it. So the how we approach it is basically having data objects using external data types. So, basically, instead of, you know, we're respecifying just contact as data objects or or and they're like, we we are saying a bit a certain property and data objects is using an external specification. So we have a a notation for it, and here's an example how we refer to the the JS contact profile. So we have the the specification identifier and the type name. So so, basically, this this how how does what such a reference could look like. And similarly here, we are not talking anything about the presentation. So the the JSON draft that I will tell about later is addressing this aspect how to how these external types are are being represented in in JSON in this case. We also made a kind of bit of changes related to to processes. So the the process itself, where we added in in zero free before adoption already. So so, basically, these are, let's say, resources which refer to to entities acting on data objects in context of data objects and but can contain their own data and operations. And they are basically a carrier of transient data, which is kind of making a mutation of the data object. So what was missing in the in the previous situation that we didn't have to renew our process object, so we added added that and the related operations to the renew. We also added a a create process, and this one has a a kind of a special handling, which is universal across all process, but but for create, it's very significant. But but, basically, you are creating an data object and the process or you can be creating the same time because before that, the objects haven't existed yet. So so, basically, it's also allows us to model something like pending create. So with with the object is created, but in in the next data, then there's still a process surrounding in behind which maybe requires some additional actions to complete. So the the period of the registration, for example, is also transmitted using this this construct. And, basically, the process object is like like an abstraction where we defines for for all the data objects and and also the the like, expression that allows to access all the process that are running for the data objects. It it is the process property, which is defined at one place and basically attached to to all data objects. Together with this, the method that I mentioned before of direct access, it allows actually a a pretty, let's say, straightforward expression of cross collection under under a data object. So Martin will show it also in the core core draft. And also the process all have the an optional process ID. So in the case, you have a collection of of process, you can access it and not only by the latest one, but also by by ID. So this is what I I mentioned. The process object have has, right now, few predefined values or or elements. So this transfer in new restore create. So whenever such process will exist, an object can can expose it. And there's an example how this process data can be passed over when creating an object. So so, basically, there is substructure, which is related to the process, not to the object itself. So then the period is not something that the main name in this example would persist, but it will be reflected in the expire dates once the process will will be completed. And then the this link below shows how the process can be accessed through the through the URL path. So in this draft, we have quite a few still open issues. So one of them is the client definition. So right now, we kind of took over what EDP was doing. So, basically, the client was an identifier, but how working right now on the draft, we tend to think that actually client itself can be a data object. So the very simplistic and the implementation can it can be a data object just with the ID. But for the clients, the registries usually have more data like a name or or other properties that they sometimes want to expose even through provisioning interface. So we think that the references to to clients should be changed to to a data objects kind of reference. Basically, even if these objects are not actually exposed by the registry, will be, like, a reference without an object where you can access, but still do look like a a reference the same way no matter if the registry would offer this functionality or not. This, again, the the topic that I think we we had during last working group meeting and but the let's see, situation changed a bit in terms of of motivation of doing the change. So right now, we are we are still having a notion that the associations with more of than one objects have the same order or the this order of the items in this call collections are are guaranteed. So, previously, we we thought it could be useful to using partial updates with JSON patch because it would require addressing an array elements with an index. So the feedbacks that we we saw so far was that it may be operationally complex to achieve to have this order always preserved and also not compatible with PPP model, which basically addresses the changes or the elements by value, in some cases, not by by any any index. So right now in the JSON draft, we specified the kind of extension of JSON patch with by value kind of references. So I think we are at the position right now to say that we want to remove this constraint or or this requirement to maintain the the order of of elements and basically move forward with the without it. And we have also some still, let's say, things that working group already kind of decided upon, but we haven't implemented it yet in this version. But just to mention, we we said we want to spend a solution to remove the out outcode from default responses, especially from info kind of responses to remove this urgent flag and to change the title, abstract, and introduction of the draft to, let's say, say, something about that it is drafted also describing the business logic. Yeah. So there are some other other issues in the queue, but we are in terms of less importance and the the next steps we want to, let's say, work on the constraints definition, which is right now a mixture of constraints and business rules. We want to make it a more distinct, let's say, work on the data elements and the formal definitions of of the formats and and the ABNFs and review the naming. We when when mapping data objects to especially to URLs, we noticed that some namings are maybe not that fortunate, and we we want to review that. And the feedback from Ayana, we we want we know that we have to reorganize the Ayana registry definition because the this is right now not handable by Ayana in this form. Yeah. So as always, any reviews are welcome, and any help for on any of the of the issues is also also welcome. Yes. So Thank you. I think this was the last slide, so if there's no one in the queue.
[00:20:25] Marco Davids: Any questions, remarks, feedback? We have room for a couple of questions now. Alright. Thank you very much, Powell. Excellent timing also. That brings us to the next presentation. That would be Maarten, who will bring us up to speed about RPP core. And I'm gonna hand you the clicker. There it is.
[00:20:55] Charles Eckel / Max Gerber: Okay.
[00:20:58] Maarten Wullink: Got it. Let me better. So since the last update of the document, we have adopted the the document.
[00:21:16] Marco Davids: This is
[00:21:19] Maarten Wullink: and the the I think Paul already mentioned that the the biggest change in in this version is that we added the organization and the user endpoints. Organization and user may be or may help us and also later on trying to see if we can make RPP more natural fit for multitenancy. And I I I think the the biggest change is that we added a set of rules to convert what's in the data objects catalog or or document into actual endpoints and HTTP methods in the in in this core document. And we formalize the the way full and partial operations should work. Oh, yeah. I forgot. The just to to, yeah, to make make everything very clear, we added this section as well to the to the core. I'm not sure if we wanna keep this, but just for any new new readers that just to make sure that, there are no misconceptions. So the RPP is totally independent for EPP. It doesn't require any EPP server to function. And, also, we had some discussions on the mailing list about how to name properties or elements. If there are also counterparts in EPP that do similar stuff, maybe prefix them or postfix them with EPP. So we decided that this would not be a good idea because then it would be more linked to EPP. And we already I think Marco mentioned the mapping to r p from RPP to EPP, which is a little bit up in the air at the moment. At least this will not be part of the core document. This will be done in in in a separate document or documents. So Pablo already mentioned, we added, organizations based on, existing, EPP extension. But we also extended it with a a user object. This would allow a registrars, for example, to create multiple user accounts for their organization. And this this user account can then be mapped to authentication schemes such as OAuth. So it it would be easier for registrars or resellers or whoever has access to the system to be in control of creation or, changes of user accounts. And what would be nice is if if we could maybe, see if we could make the registry itself also an organization. So then the the registry could be the parent of a registrar, and the registrar could be parent of resellers and so forth. So this this would allow us to also have multiple registries in a in a single system, in a single database, for instance. We'd make it easier for if you're running multiple TLDs and, you know, you don't wanna set up different environments for all these TLDs. You can run them all in a single environment if you would like. So the core document specifies the HTTP methods and and URIs to use for the API, and these are derived from the objects in in the data objects catalog. And we came up with a with a with a set of rules that if you follow these rules, you end up with a set of of endpoints that you can use. They're a bit pretty basic, so I'll go through each one of them. So the data objects identifier for each object. For instance, if you're looking at the domain name object, if you follow rule one, you end up with the collection path for domain domain names. So the identifier for domain object is domain name, so it plural would be domain names. And every uniform operation, so it's like the the normal operations create, read, update, delete, It's mapped to a HTTP method. So if you wanna perform the create operation on the domain, it it would be following these two two rules. It would be post to domain names. And rule three is, about mostly about processes. So, we need a way to also formalize how do you access, sub resources for so everything under domain name slash, my domain slash whatever. Processes are, according to rule three, are just sub collections of a specific, domain name or a specific, contact. And for rule four, the processed uniform interface is basically kinda similar to what's what we're what we described for the normal interface operation. So for processes, you also have the, CRUD operations, which are also mapped to HTTP methods. And rule five is a little bit different. So if you have extended process operation, for instance, if you have a transfer operation, you have a cancel transfer or delete transfer, then currently, we were saying in the document that you should probably all always use post for that. And for process listings, you can get you you can choose if if you want all the currently active processes or may maybe even process that already finished. I I guess this is more like sort of a policy or processes so you can show the return. You you can choose, I want all the processes, like, give me all the transfers, give me all the renews, whatever, or you can filter down to a second second level collection where, for instance, I do say, oh, okay. I only want the transfer processes, so then you go one your path segment deeper. This one is is kind of obvious, but we we we added it, of course, because we need it. Updating an object, we we identified two ways of updating a document. This was also in the requirements. We should be able to do a full update or replace the complete representation of an object and be able to do a partial update. So for the full update, you should must use the patch. Oh, sorry. For full update, you must use the put, which should where the body should contain a a valid complete new representation for the object that you are replacing. And for patch, oh, sorry. I keep it too. For the partial update, you should use the patch method. And, Powell will later on in in his presentation will show how, we modeled the the JSON for doing the patch. And as a result of of of of operations, such as a transfer, sometimes, not not always, but usually, a process is is started. And this process, it has its own identifier. And the the URL to this process with this identifier is returned now as a link header in the response. So there's an example in below in the slide. I don't know if it's if it's visible in in the in the back, but it contains a a new RPP dash process relation type, which is also in the AYANA registration request. And the next steps is we're gonna we already got a lot of feedback to go, so we're gonna process that for the next version. We need to need some way to map data objects elements to HTTP request parameters. And we also need to make sure that the everything that we do and and say in in the in the core document is compliant with, what the HTTP directed requirements are. And we're still need to remove the option for, profile signaling where we now have two options, the header option and the media type option. So I think we decided that we wanna go for the media type option, so we still need to remove the the header option. That's it for me for the core.
[00:30:03] Marco Davids: Thank you. Excellent. The queue is empty. Any questions? No. Alright.
[00:30:14] Charles Eckel / Max Gerber: Brings us to the next I put myself in
[00:30:17] Gavin Brown: the queue because I have a question. Sorry, Martin, if you could come back. This is, obviously, me speaking in my individual capacity. I wanted to ask about and there's been some discussion on the chat about the parent child relationship between registries and registrars. Is that something that is a necessary aspect of RPP, or is it something that's optional? Because I have wanted to ask about the scenario where you have a multi tenant RPP server with multiple TLDs that may be managed by different entities. But you may, for example, have a registrar who is a registrar of multiple TLDs on that platform and therefore can't re strictly have a single parent to which it can be associated.
[00:30:58] Maarten Wullink: Yes. Good point. So this is fairly recent. So I I I think I'll, put this question to the to the list first and to see what what the opinions are. This was just something that I figured, okay. This this might make sense for, multitenancy situations, but I'm not the expert at at multitenant, registry system. So I I I think we could use some feedback here from maybe registrars and other registries.
[00:31:32] Marco Davids: Alright. Thank you. That brings us to the next presentation, and that would be Powell again about r b p json. Powell, you want the slides again?
[00:31:50] Pavel Kovářík: Yes, please. Yes. So the the the the next from the quite recently adopted drafts. So here, we are talking about the the mapping itself from from the data elements to the data representation and to the data structure. The so because it's quite a fresh draft, so just a a quick reminder what it what it does. So, basically, it defines the rules of expressing data objects situation. It's depend let's say, contains JSON schemas for different kind of representations needed for creating, creating, updating, or referencing objects. Maybe we'll need more, but so far we have this this form. And this adopted. Yes. So what we edit are, let's say, new schemas. So kind of following or in sync with the other drafts, especially data objects. So we have the schema and examples for transfers and the approve reject cancel operations. We have the organization and user user objects also added to the to the JSON draft to schemas and examples, and we also added the renewed process object. What we also added here and the the the counterpart to what I mentioned before is the support for the external types. And we we are thinking, okay, how how we do it the way whether it's not specific to JSContact, but, let's say, generic that can be used to an external type. So so right now, we we can come up with this free approaches that adjacent presentation should take. So if the external type has a native JSON representation, it can be just embedded in the JSON tree. If it has a native UTFI eight encoded text representation, but it should just put it in the JSON string. And if none of the above applies, it would means meaning meaning it's just kind of a binary block of whatever form, then we just define, okay, this should be just base 64 encoded and put into the JSON string. So, basically, this way, we are, let's say, putting the rules for for embedding any kind of external objects. Right now, we have a use for for this contact, which is the the first case. So how how it how it looks in the data objects, we just define this contact info of the type external JSON let's say, JSContact card. And as you can see, up from this point, it's a a regular JSContact two point o card object, which which basically has all the properties with with. We have later representation about the profile for RPP, which actually defines how exactly this JSContact object is is constrained for RPT. The second addition was the embedding of of process data. This is what I I shown before. The process actually is a data object element, and the the create process process is the property of it. So, basically, you have the executive presentation in here, and the create process basic is basically the create process object. And what Martin also mentioned, so we needed the representation for two kinds of updates. So the full update, and this one is kind of easy because it's basically the full representation of all writable properties. And most tricky part is the partial updates. So it's in needs a special representation to express what what changed, and the RFC 6902 JSON patch was not sufficient due to this mentioned ordering of our eyes. So we started with the approach of EVP like representation with add remove change properties. Right now, what we ended up with is a bit more close to RFC 6902. So, basically, it's the same structure with a bit of addition for matching by by value. So for sure, this needs some implementation experience if it works out as as we envisioned. So this is a simple example of, let's say, replacement operation, which which doesn't require some some matching because registrant is a simp let's say, one sing single reference. So, basically, there's, like, 60 now, like, JSON patchwork work. The the other example shows the adding part. So this is also easy because there's a a path defined and you add a a value. This is the most tricky example where you actually actually, you have to make the the matching by by value. So, basically, you have a object where where where the label is for the status is okay, and you have an array of statuses. So we don't know which element of the array is actually the the one with the okay label. So this expression just tells you that you should look at the array at this, let's say, status path, make a matching of all properties, but it's in this match object. So in this case, it's only on the label, and you replace all the elements which are matching with the single value, which is in the value element. So let's say, usually, it is a big one to one object to replace, but you can also make a matching to replace all the all the objects all the all all the elements. Yeah. So what's what's still open in this draft? So we have an open issue about localization aspect of data writing. So this at least what what is right now in the architecture draft saying that for reading, we can use STP content negotiation to get the required data and the required localization. This may fall short if the client actually wants to receive all the localizations because if the if there's we we are talking about provisioning, the client client would want to to read everything which is written in the registry, not only in one language, at least for for some use cases. And also for for writing, the client wants to provision all localization at once, not to have to make run trips with different localization. So I think we have to hear a bit different situation and and and requirements. So the proposal that you have is to use a special key, like so we are we are using this notion of of at sign or at character to to indicate properties which are, let's say, own special meaning. So we would use here at localizations for for localization data. Similar, like, similar approach like just contact us. And if the client would send the accept language header on the then return on the preferred language and and other and other situations as we John just return all the localization of this special property. I think that this would have to go to the the call draft, but I think this has to go hand in hand. So I would love to hear any feedback about this approach from the working group. Rick?
[00:40:45] Rick Wilhelm: Hi, Pavel. I I'm gonna ask a stupid question. On slide eight, there's a thing about, two types of updates, and there's a a statement in here where, RFC sixty nine zero two JSON paths patch is not sufficient. Okay. As though we're doing something here to JSON that an existing RFC doesn't accommodate. Like, we're doing something novel.
[00:41:23] Andy Newton: And I
[00:41:24] Rick Wilhelm: I I just kinda find that hard to believe that we're doing something so novel in JSON that we've gotta do an extension to handle whatever it is that we're doing, that somehow we're doing something so stretchy and curious here that we've gotta add on to something that's got a relatively low number in sixty nine zero two. So but, again, I this is a a stupid question. So maybe somebody here that knows maybe you or somebody here that knows something way more about JSON than I do, and that's a low bar, man.
[00:42:02] Pavel Kovářík: So so so it's a simple simple answer, which I I think I I tried to at least convey this message before. It's not about JSON itself. It's about, let's say, immutability of the objects that we transport. So if you the JSON patch is actually assuming for error modifications that the indexes are stable. And this is something that in our provisioning environments, cannot really guarantee all the times. So between reading of the objects and even two times, there's no guarantee that all the items on the array will be at the same place. Like, maybe it's just the the database returning the things in a different order, and there's something that EPP doesn't care about for so far, and I don't believe and this what's what's also people are telling that we can expect from registry deployments to guarantee. So this was was the point that I had on the data objects draft saying that we had this requirement basically in a vision of with that we can use JSON patch, but it seems that this requirement can be hard hard to implement or will put very serious constraint on the registry system. And I'm not talking about JSON itself, but about about the underlying databases be let's say, below it.
[00:43:37] Andy Newton: Andy? Hi, Paul. It's Andy Newton speaking as an individual. So the external data representation, the base 64 and UTF-eight and whatnot, one of the things I think you would find a little bit odd is if you took a PEM encoded key and put it into a JSON string, because you think it's UTF-eight because, the the what you would end up with is something you'd probably have to base 64 encode, but the actual key material is already base 64 encoded. So it might be that oh, I wanna think a little bit harder about this. Make it maybe make it extensible, whatever the the framing is around these external types because I don't think it's gonna I don't think every textual representation is going to map cleanly into what you would think native UTF-eight would be in JSON. And and specifically with PIM, think about the the fact that you have to escape the new line characters and things like that.
[00:44:32] Pavel Kovářík: Alright. Alright. If you if you have a any smart wording about it, I'm happy to also see it on on the main list.
[00:44:39] Andy Newton: No. No. You've gone too far. Don't I don't think so.
[00:44:43] Marco Davids: Okay. Paul, can you please move ahead again to
[00:44:46] Pavel Kovářík: slide this. We are right here, I guess. So there there's also an interesting aspect. So we have right now in the draft normative JSON schemas. Let's say you're using 2032 reference. So there's a known problem at the IETf, but it was somehow problematic due to no normative IETf draft or IFC. I I know that this problem is now there is now a working group, JSON Schema, which is started to work. We're targeting May 2027. I looked up the the milestones, so it's after our IPP RPP milestones. And we think that it's still useful for implementers. So this was, let's say, possibilities that we see is wait for JSON schema. There's one thing one one possibility. Change JSON schemas to non normative. So, basically, the actually, we have a deviation from data objects, and so the schemas don't don't have to be normative in in the in fact, for the the things to be implementable. This also will help in case we have inconsistence between JSON schema and, let's say, the variation from from data objects that we know which is the sort of true. Use something else. CDDL, I think, is the the option, or do nothing now and wait. Let's see and see how how JSON's came out evolve. Yeah. So think we're we're just some closing parts of it first. Any opinion of this? I I think this is more valuable than me talking.
[00:46:40] Andy Newton: Alright. So Sandy again. This time speaking as a responsible AD for the JSON Schema working group. What you could do is you could take a normative reference on the JSON Schema doc and then just send it through you you can send it into the into the RFC editor's queue, and it would just sit there until JSON Schema gets done. So you wouldn't have to move your milestone if you didn't want to. Of course, that would be dependent on whether your responsibility agrees to that or not, but that that is one possibility.
[00:47:08] Pavel Kovářík: Which is basically the same as aligning them the milestones. Alright. Yeah. So with and other opinions, we are happy to see over in the mailing list, there are some few other open issues in this in this draft. So I think the the next steps is review against data objects and assure completeness, synchronize all the schemas with data objects. We know we we have gaps there and and cover the other open issues as always. Some review would help and and feedback over the in the mailing list or over the GitHub and implementation experience, especially with updates representation would be would be very helpful to to know whether we are on the on the right track. Thank you.
[00:47:58] Marco Davids: Alright. Thank you very much, Pavel. That brings us to the next presentation, and that's you again, Pavel, about JS contact profile. Mhmm.
[00:48:10] Pavel Kovářík: Yes. So this is the the last piece in the in this puzzle. This one is not yet not yet adopted. But if if we move this direction, it is very very needed. So this is we are still in the same area of the architecture, but here, we're not talking about mapping because it's direct use of the external type. So we are we are just defining directly the the type. So what's the best baseline why we are why doing it? So first, we have this requirement, but should consider using JS context. So we are trying to consider it with this approach. The RFC 9553 defined the JSContact two o, which is generic enough for us to use it and as a JSON representation, which is good. The there is an still active draft about defining the profiles on the JS contact 2.o, which basically allows us to define a subset of properties needed for our use case and not necessarily support everything including, I don't know, cat's photo or or whatever else JS complex supports. And finally, we have a draft active draft in regex related to RDAP, which is in from the same kind of domain. And it is there's already this the draft defines a profile of this contact for other protocol. So this draft with I'm presenting is actually doing the same for for RPP. So what's the relation to ad up and what we are doing separate profile at all? So reviewing the ad up profile right now, we see few places which can be problematic or at least that some data elements are having, let's say, more than one representation. So we have name represented as full name and, like, components name where first name, last name is is separate. We have also address data, which is can be expressed in full. So one string or components where where streets, city, and ZIP code are separate. And we have country code, which is also or the country, which is part of the components, and we have a country code, which is, let's say, containing the country code itself. So there's the ambiguity, but we think it's not appropriate for provisioning pro protocol. And, some of these pro properties are not mappable from our two RFC 5733. So in this profile, we actually narrowed down the the choices. So for each element, you have just one choice. So the for the name, there's it's only the full name. For the address data, there's components limited to name, locality, region, postcode. The cup the country is left out because there's a country code with ISO code for the for the country in the right now, the email, phone, and fax are defined as a single instance, but I will refer refer to that because that this that's something we have to probably change. And other properties and profile mechanics like prohibiting fetch objects and and alike are exactly the same as in the RDAP profile. So as a consequence of of doing this, this profile is basically a subset of of RDAP, which means that all RPP JS contact can be used in RDAP as is, but it's not true the opposite way. So the the RDAP JS contact can be only used for RPP if this subset is is in use. If any of the elements which are left behind are used to the the client would have to transform them on their own. Yeah. So there's also the approach that we take about localization. So the RFC 5733 has a notion of international lock local variants of contact postal data. And we discussed it last in the last working group session with the let's say, all ASCII variants is probably not, let's say, too constrained for the current needs. So what we say now that the JS contact shall, let's say, have this primary language. So the the language where this whole object is expressed with to be international post addressing contact, whether whatever it is, I'll ask you or not. The question which may be asked, okay, is it something that we should tell in the profile, or is it a registry policy and should be regulated elsewhere? If, for example, such registry would act act only in the local market and will never need an international address. Maybe it's because training, if we we say it in the in the profile. And any other language and localizations element of just contact basically is equivalent to the local version EVP. So the server policy may limit it to to just one. So for EVP compatibility, it will be a a hard requirement, but for operational reasons, it may be even reasonable to to keep the limits at some level, not to allow, like, 100 localization of the same address because that probably there's no use for it. Yeah. So this is what I what I mentioned. We have the, let's say, reviewed, but the requirement actually the c one one rights that we should support a priority of voice fax numb fax and email addresses. So this is where we probably went too far by cutting down the profile, so we have to to revert that. The other profile has as it's defined right now, has the deministic keys, which is which is good, which is should be sufficient for for provisioning as well. So as long as this stays true, it we can maintain the compatibility with other profile on this level as well. We have also links which are on the other profile. But can be useful for some provisioning object like organizations. They are not existing in EPP. So there's a question mark. Do we want to keep them? I think they are quite a universal tool we can we can keep. But if someone has valid reason to say we should remove links as well, please bring it to the mic line or or to the list. And some things that we have to, let's say, analyze is how the extensibility of the profile would work. So how the process would look like if we would need to add some element. So would we make a changes to JSContact? Do we have to go through some, let's say, registry of JSContact properties first to add them to the profile, or we we just say that this contact is kind of defined in the profile and frozen, and everything which is added on top, it would be in the embedding data objects. So these are some elements that we have to to make some thought of. Yeah. So we think that the document is right now in the good shape for working group adoption and but the this necessary piece of adopted work. Let's say, if we if we the working group is convinced, we should go in the JS contact direction. And when the the open issues, have to tackle them and and expand with implementations. We have closed queue and time remaining, but no no one queuing. So
[00:57:09] Marco Davids: We have some time for questions or feedback if I can unlock the clue. Oh, it's already unlocked. Okay.
[00:57:17] Maarten Wullink: Okay.
[00:57:21] Marco Davids: Thank you. With regard to working group adoption, we we will take that up with you guys and facilitate the discussion on the on the mailing list. That brings us to another piece of new work, and that is, the RPP OAuth idea from Martin.
[00:57:46] Maarten Wullink: It's not only my idea. Don't blame me if this goes wrong. Okay. Not kidding. So this this is something we looked into. It is OAuth because we figured it would be a requirement for more more advanced use cases that would depend on OAuth. I'll get back to this point later. If you look at the requirements, our clear requirements that's that's that's state, okay, we should have something like, oh, out out authorization that's actually explicitly explicitly mentioned as well in in in the requirement nine dot two. It also says, okay. Yeah. You need to have a granular auto authorization system or matrix and and modern authorization schemas in RPP. So this this kind of naturally fits with the with OAuth. So if if you if you have an OAuth system, then for RPP, then both the registry users and registrar users could be provisioned in the in the in the same authorization server. For instance, a registry could create accounts for the support staff for, helping, registrars with questions. But, these these accounts are then limited in scope, so they can only look at certain objects. And you can also configure admin users, for instance, that may be able to update certain areas of objects to where where if there are any issues with where the system somehow breaks down, where manual intervention is needed. And, of course, the registrar also has access to the authorization server. And in in the most ideal case, they could self provision their users and use this fine grained access model that's that's that's possible with with OAuth where you can, as a registrar, can say, okay. I have different just like a registry, I have different types of employees. The support, employees can can look at of have read only rights so they they can find out information about the registered domains. But I don't want, normal users to be able to do transfers or, up the leads or more destructive operations. So the this this would would help registrars with with, yeah, also securing the system on their end. They could use, like, the the the what's it called, the principle of least privilege within their own organization. I'm not sure if this is a redo all the way in the back of the room, but this is from the from the draft. This is and and and bear in mind, this is, the the first try. So and I'm not an OAuth expert, so there might be things horribly wrong. So that's why I hope there are also people here that have lots of OAuth experience. Or I know there's OAuth group here, so we'll definitely be talking to those guys as well, if you continue with this. So this is an overview of how, an OAuth deployment could look for RPP where there's a central authorization server where both registrar, and registry applications connect to and where employees from both registrars and registries can authorize or at least create create tokens, access tokens for, and then get access to the registry system. So you can have different types of flows, authorization, authentication flows. So the one is, you can have an interactive flow that's basically a user using a website, starting a transaction, maybe creating a domain name, has to log in manually using some web UI, or you can have a machine to machine flow where it's basically automated systems talking to each other, which is, what you usually have with with, EPP. So it offers, scopes where you can specify, like, the authorization for authorization access. So the server can enforce access controls. There are lots of default scopes for these are also specified in in best practices, and we added a few new scopes. And these are, again, like other like, in the core document, these are derived from data objects in the data catalog or the data objects draft. So a scope has has a has a simple format. It's just the name of an object separated by colon and then the access level. And so this is an example for a scope for the domain name object, which is basically just follows the CRUD pattern. So you you can have a scope that's that has domain w, colon create and scope, colon read. So and if I, as a user, log in, I select the scopes that I want to, request. And if the server agrees, then I get an access token, which is scoped for these operations that I can then send to the server if I wanna do something like a domain create. And if this token doesn't have these these scopes, then the server will have to deny the action. Claims are gonna also, again, an old wealth thing. These are more about identity. We find two news RPP specific claims. One is and these work together with the with the the subscope, which is basically the username with when you log in. And so the two claims that we identified so far was the claim for the register ID and the claim for reseller ID. So if you include these in your access token, then this access token will then have all the information the server will need for authorizing operations. It doesn't have to go back to the database, for instance, for looking up what what reseller or what registrar is linked to this token because it's already in the token itself, and it's signed. It's it's verified so we can trust the token. Well, our future work well, as as I mentioned, this is just a first attempt at this, so we need a lot of work here. And this is definitely not gonna be part of the of the of the core document. We still have to see, okay, how important is this? How much time do we wanna spend on this at the moment? Because as I mentioned at the start, we we I I first when I when I started this, I thought, okay. This is something we need for more advanced use cases, it says secure delegation management or secure transfers. But after doing some more work with those and also implementing a secure transfer at Hackathon, I figured that it doesn't really require OAuth at all. So we need to figure out, okay, if if if we wanna drop OAuth from those two advanced use cases, then we don't definitely need OAuth at the moment so we can give it a lower priority. So I'll I'll put that question to the mailing list. That's it for now. Any questions?
[01:05:29] Marco Davids: There are there is some discussion going on in the chat. I'm not sure if anybody cares to step forward and or just leave it in the chat. Okay. No? Alright. Oh, Pawel is in the queue. Yes, Pawel. Please go ahead.
[01:05:48] Pavel Kovářík: Yeah. Matt imagine if you can could just skip to this slide before. So the the one after. Yeah. So I'm I'm not think I'm not thinking that we are really talking about lower priority on on the off to as such. At least this is what I also wrote about the the chat, but we should still or this is what we put in the requirements cover to come up with something better than basic basic out for RVP. And off two is one of the possibilities, at least the one that we wanted to explore. So in the basic machine variant, I I I think we should still explore this way. The more ex let's say, advanced use cases that you mentioned about authorizing users that may be maybe, let's say, bonus on top. Once we have such deployment, you can also try to benefit of it. Yeah.
[01:06:52] Maarten Wullink: Yeah. So with with lower priority, it does mean low priority as in work queue. So then we first work on the the JSON documents and and the core. If you and if you have time, then look at this stuff. Yeah.
[01:07:11] Marco Davids: Okay. Thank you. And you can stay on this stage because the rest of the show belongs to you.
[01:07:19] Maarten Wullink: Some stage.
[01:07:21] Marco Davids: We go to another idea, the OS transfer slides. And you have some time. We're a little bit ahead of schedule, so that's okay.
[01:07:38] Maarten Wullink: Oh, I'm oh, yeah. Okay.
[01:07:40] Marco Davids: Hold on. I'll give you the slides. So yep.
[01:07:46] Maarten Wullink: Yeah. So as as I said, okay. I I I thought I would need or really would need a while for this after more work looking into it, so I'm not that convinced anymore, but doesn't mean we don't want this. I I think it's very cool, and we should definitely look into it. So this is about, an alternative way for doing object transfers between two registrars. This this is also clearly stated in the in the in the requirements that this is something that we want. We want a more simplified, easier way to transfer objects between registrars. And we also wanna wanna if if if possible, do away with the authorization info token, which is clearly not the most secure part of EPP. So that I I think there is room for improvement there. So this is kind of a, first attempt at looking at, a possible solution for that. So and and the goal is just, okay. Can we can we look at coming up with a way of, designing a a a transfer mechanism that is both secure and and user friendly and user friendly? That's what I I mean, like, the the the the registrar, where the the registrar can simply click on in a flow, in a in a in a a on a website, log in, and click, and it's done. So it's as frictionally friction free as possible. Then this this is only for the pull type transfer, of course. So and and the the gaining register should should not have to know anything about the the the the current registrar. So that's important because you cannot have all these registrars knowing about each other and where to connect connect. So as I mentioned, don't use the info or the info token. And one of the nice things is, okay, if you don't use our info token, but we use a cryptographically signed, JWT, for instance, we we can have a much more secure, transfer, approval mechanism. We can have a limited lifetime, for instance, with then we can add. We combine it to a specific registrar. We can do lots lots of other stuff as well to limit the the the way the token can potentially be abused. And this is also, I think, a nice example of of how we can use RPP to do stuff that's not easily possible in other solutions. And, yeah, based on OAuth two, I'm not so sure about that anymore. I'm not sure if we have time for for this.
[01:10:45] Marco Davids: Yeah. We have a couple of minutes.
[01:10:47] Maarten Wullink: Okay. So the basically, the idea is, okay, you have a registry and registrars. Registrars register a authorization endpoint at the registrar together with their public key. Then when a registrar wants to transfer or or a restaurant wants to transfer a domain name, The gaining registrar looks up the losing registrar through the registry API, gets the endpoint, redirects the client, to the endpoint. The client needs authorized at the at the losing registrar endpoint, then clicks the auth okay button. This is this is this is valid. I want this. Gets redirected back to the original registrar UI, and then the registrar can, send the transaction together with the authorization token that it received from the losing registrar, which is signed by the losing registrar, can send it to the registry, but the registry can validate this token, say, okay. I have a valid approval from the losing registrar and can go ahead with the transfer. Yeah. So as I mentioned, so this this this works. We we we demoed it during the hackathon. But as as I said okay. So it probably doesn't need OAuth two, and it might be more interesting to look at the more general authorization mechanism for RPPs for allowing third party access to registry objects, which is then separated from the authorization mechanism such as OAuth two. Yeah. I wanted to show a live demo, but we we tested this before the session, and it's, like, one frame per minute. So that's not gonna happen. So I I instead of the live demo, I have some screenshots, during the actual recap. Any questions?
[01:12:46] Marco Davids: Are you interested in collecting feedback on this?
[01:12:49] Maarten Wullink: Yeah. Yeah. So, this is, like, a a first try at at investigating how how something like this could work, how a more simplified transfer could work. And and, basically, at at this point, we're I I've been looking at the vantage point from the registrant. So how can can we make it easy for the registrant to transfer domain names or objects. Like, keep it general. And all and and and have it as secure as possible. I know that there are conflicting interests that sometimes registrars or other parties like friction, but that's a whole different subject. But I I I definitely would love if people would join and and help brainstorm, okay, how how how can we come up with something that would work in the real world? Because I'm not totally sure yet if this will work actually in the real world. So because it depends on registrars also offering or or having an endpoint to connect to. So there might be some need for incentives or making life much, much easier for registrars in some areas for them to want to be able to do this. So there are lots of open questions. And
[01:14:04] Marco Davids: have three people in the queue. So let's give them a chance to respond. Pavel, you first.
[01:14:12] Pavel Kovářík: This only the remark about, let's say, not seeing a point of using all for this use case. I think you should not give up on all that easily just because it's let's say, kind of worked in the demo environment because OAuth had been developed for several times to assure that all the flows between different domains and the the user agent are actually secure, but but there are enough of information flowing between the parties. We redirect URI's state and all the controls around it, and, actually, you may end up redoing the the work which has been done already, and that that is that's something to to take care of.
[01:15:00] Maarten Wullink: Yeah. Yeah. So I I didn't mention to say that you shouldn't use OAuth with this because you can use OAuth with something like this secure transfer, but it doesn't depend on it. So if you wanna use another form of, authorization, not OAuth, then it should also work. And so if you bind it hard to OAuth, then you should then you have no option to use other secure forms of authorization also if you would like.
[01:15:23] Pavel Kovářík: Oh, okay. Alright.
[01:15:25] Rick Wilhelm: Rick? Thanks. Rick Wilhelm. I think this is very interesting work. I think, however, that the issue about transfers and friction is a policy problem and not a technical problem. And so I don't think that it's really worth it to sink a lot of effort, intellectual effort into this until there's a a until the policy door opens to allow a technical solution for pull driven transfers to be usable, because it's it's a it's a policy problem, not a technical problem.
[01:16:09] Maarten Wullink: Thanks. Yeah. So so you're saying don't don't work on this now. Or
[01:16:13] Rick Wilhelm: I wouldn't I wouldn't I wouldn't invest time in it. I would and I wouldn't recommend that folks invest time in it until there's a policy until the policy situation opens up in a particular context such that there's interest in in a pull driven transfer model. Because if the transfer and if RPP builds its transfer model solely around a pull driven, it will definitely hinder its adoption. And I said solely. I'd so I I'm assuming that RPP is going to support also the traditional transfer model.
[01:16:54] Maarten Wullink: Yeah. Yeah. Yeah. Of course. So this would be, a a new feature for RPP.
[01:16:59] Rick Wilhelm: Yeah. I and I but I still wouldn't really invest a lot of time in it because it will confuse people by having both of these, and it will policy people that are involved in this will will not see it as clearly and plainly that's an that it's an option as the people that are listening to this recording will. And so I would I would I would not invest a lot of time in it. Thanks. Even though I think it's interesting technical work.
[01:17:30] Marco Davids: Yeah. Noted. Powell, you're next.
[01:17:35] Pavel Kovářík: It's just a reaction to what Rick just said. So the policy question only applies to GTLD, and that is what I hope that Rick wanted to to say. So so I think in CCTLD works with this kind of easier to to introduce such such features because they are not bound to the, let's say, external policy work in the in the sense. So so it's gonna be still an interesting work to experiment with.
[01:18:06] Maarten Wullink: Yeah. That's a good point.
[01:18:07] Rick Wilhelm: Two two fingers. And and, yes, Pablo, I know. But it the the point still remains. If if there's a CCTLD that it I would still do the work in the CCTLD community first and still do the policy work to make sure the policy door is open before investing a lot of technical work. I understand that that an environment like center might be a might be a better place to get traction for something like this, and I'm fully aware of the distinction between the ICANN GTLD world and both the center world and the noncenter CCTLD world. Fully a thousand percent aware of that, but just do the policy legwork before spending a lot of time on the technical legwork. Thank you.
[01:18:52] Marco Davids: Okay. Thank you very much. That brings us to the last presentation before the hackathon recap, and that would be OOut for delegations. Let me see if I can give you the slides. Yes. Go ahead.
[01:19:11] Maarten Wullink: Yeah. So this is kinda similar to secure transfers, but instead of transferring domain name, it would update delegation information such as DNSSEC information or NS records. And instead of, going through the DNS layer, for instance, with, CSYNC and stuff like that and scanners, you could try and see, can we do this, at the, registry level or at the provisioning level? This is also from the from the requirements where there was a require or is a requirement that we should investigate if DNS operators can be allowed to update their or update DNS records directly in the registry database. Yeah. It's kinda similar as the the previous secure transfer. So can we come up with something user friendly that will give DNS operators access to the registry database? In this case, the the DNS operator would need some agreement with the registry to be able to perform operations. And the the workflow would would be kind of similar as in the transfers and that the registry would be kind of the middleman redirecting the the the client from the DNS operator to the registrar that is managing the domain. There, the approval process would continue, and a signed token would be returned, which is then returned to the registry. And then, voila, DNS records are updated.
[01:21:01] Marco Davids: We have Jim in the queue, so, you wanna have some time for questions and answers? Yeah.
[01:21:06] Maarten Wullink: We can do it in between. So
[01:21:16] Jim Reid: Thanks. Jimmy, just a random punter on the street speaking for myself. It's not so much a question, Martin, but it's more of an observation. You're probably aware of the stuff that Johan has been doing in DNS op. Yeah. So we may hopefully be moving away from last year doing c scanning and stuff like that to try and pick up the key information. Johan's got a draft, which I think is very close to completion, which is going to be saying using a a six zero sign notify mechanism so that clients can see to the register of the parent zone, I've got a new key for you. Please come and get it. And maybe that's a mechanism that could perhaps be folded into the work you're doing here. It's just a thought.
[01:21:56] Maarten Wullink: Yeah. Yeah. So I I I saw his presentation, and it's I I'm not sure how it would be possible to combine those things. I I think if you go the the provisioning way, it would be easier, I guess, for clients to authorize kind of this this updating of NS records and maybe also easier to retract approval? Or because I I think that what is what you all mentioned is still an open issue. Yeah.
[01:22:26] Jim Reid: It's all good. Yeah. I think it's gonna be some kind of shim module that sits in between the registered database interface for CPP or RPP and the end client device, the dynamic update mechanism that's being used or the notify mechanism that's being used to transmit this information. I think that's still to be worked out. Yeah. But the fact is, I know that he's that the he's quite keen on this because the the overhead of doing all the scanning is something that's quite painful. And this is a much simpler, and I think also a much more elegant solution.
[01:22:55] Maarten Wullink: Yeah. I totally agree. So, again, so this doesn't require OAuth. It it can co coexist with OAuth. So you can use OAuth for the authorization part when you use this, but you also can use other authorization mechanisms if you'd like. So it it if if we want to support something like this, it would probably benefit from having a more generalized authorization mechanism, some kind of authorization endpoint where you can send different types of requests for different types of third party access to, objects in the registry database? Yeah. That was a short one.
[01:23:49] Marco Davids: Cool. Excellent. That brings us to the last part, which is the hackathon recap.
[01:24:01] Maarten Wullink: Yeah. And that's going back to the last two, presentations. We haven't, I don't think we have discussed this on the mailing list yet, so I'll I'll start discussion on the mailing list as well about these two subjects, if it is something that we should spend time on and if this is the possible solution or not. So last weekend, we had the the the rpp hackathon at the I t f hackathon, which was a very nice weekend. And I hope that more people will show up at the hackathon because it's also always a nice event, and the lunch is, very good. Also, dinner is also very good, at the Saturday, so it's definitely worth it just for that. We had a nice group of people this time, and we had some interesting results. The we had working code, a prototype of a Vibe coded registry and registrar server front end where we demonstrate demonstrated the secure domain transfer using OAuth two, but it as I mentioned, it should also work without OAuth two. Worked on implementation of RPP at and also had some very good discussions on things related to RPP. So this is I wanted to do a live demonstration, but I said the the frame rate from my laptop through the system here was in seconds per per frame, so this is not gonna happen. So I I created a few slide, screenshots. So this is the the dummy registry, Acme registry, where registrars have, registered domain names or have domain names under management. And I wanna transfer a domain name, coyote.example, from registrar a to registrar b. So what do I do? Let me first say, okay. Registrars, in this case, when they start up, they send their endpoints and their, public key to the registry. Doesn't have to be at start up every time. You can do this only when things change, for example. So I'm a customer at registrar b. I log in into the registrar portal, and I say, okay. I want to transfer my domain name from registrar a. So I enter the, the domain name into the transfer, screen. I say, okay. Start to transfer. What happens then is the register b request the the endpoint of the register a from the registry, or it can also already maybe already know it. Has it cached? Or maybe there are ways to get get this in bulk every every day and only get updates. There are multiple things with that we can figure out how to do this. And then, the client is redirected to the portal of register a where it, again, needs to log in because it needs to authenticate. It has to prove that it is the client that it's saying that it is and that it has access to this domain name. So after login, I end up at the portal for register a where the domain name is currently trend, managed. So I click on the approved transfer token. What happens then then the registrar creates a date JWT token, which contains items such as the domain name, the the previous registrar, the the new registrar, dates, signs it, and then puts this as a, in this case, base encoded parameter, request parameter back on the request, which is the redirect to the original registrar, registrar b, where I end up. And the registrar b then can complete the transfer by sending the transfer request to the registry with the token it received from the, from register a, and red and the registry can validate that the token is from register e because it can check it with the public key from register a, and then it accepts the transfer, and the transfer is completed. And this is all without using the, o of info of of the info token. And this is basically what we, tested out during the hackathon. And for a user, this is nice because it just log in, click, say, hey. I wanna move this domain name and click, and we're done. Users have no idea about I
[01:28:46] Marco Davids: wanna give Max a chance to respond.
[01:28:56] Charles Eckel / Max Gerber: Hello, Max Gerber. I don't know anything about RPP, but I'm a fan of OAuth. So this doesn't use OAuth? This example uses OAuth. This okay. I heard passing query parameters around and redirecting, and there are a lot of security vulnerabilities that we found over the years related to that. OAuth is the best way to do it correctly. Yeah. And so you said this does use OAuth, but you're also interested in ways that don't use OAuth?
[01:29:26] Maarten Wullink: Possibly. Yes. Because I'm not sure if OAuth is is a solution that we wanna mandate for something like this. So maybe there are deployments, registrars, or registry that don't, for some reason, don't like or don't want or cannot use OAuth, then maybe it should be possible for them to still use some other authorization mechanism. But OAuth is is, for this, probably the best choice.
[01:29:54] Charles Eckel / Max Gerber: Mhmm. Yeah. Thank you. That makes sense.
[01:29:58] Maarten Wullink: Thanks.
[01:30:02] Marco Davids: Alright. We're time's up. So do you have some final slides to show us? Or
[01:30:09] Maarten Wullink: No final slides. Oh, yeah. Oh, oh, I do. So I've learned, yeah, we don't really require OAuth two. It's still it it's it's maybe advised to use OAuth two, I would say. And we we can look into can we reformat or refactor this into a more generalized form of third party access to registry data? There is code. If you're interested, you can run the demo yourself, and that's it. Thank you. We still have some, RPP caps. So if you don't have one and you want one, just come and get one.
[01:30:48] Marco Davids: They're over there. One is reserved for you, so you have the first choice to get one. Everyone, this brings us to the end of this working group session. I would like to thank, everyone, participating here today. I would like to especially thank the author slash editors who did a lot of work. I could tell that at first hand because I'm sitting next to Martin at the office. I want to thank, obviously, my co chair who also did an outstanding job in managing slides and time and helping me out. Of course, the participants in the hackathon. And last but least, I would like to thank the note takers. I'm looking forward to what they wrote down. And I hope to see all of you, again to see I hope to see you soon again at the next ITF meeting. That's it. Thanks. Thank you, Gavin.