Session Date/Time: 21 Jul 2026 09:00
[00:02:18] Lorenzo: Perhaps we should get started. It's two minutes past May someone. Thank you. Thank you. Okay. Welcome everybody to the ASDF working group meeting at IETF-one hundred twenty six in Vienna. Kindly ask someone for note taking volunteers. Thank you, Adi. Okay. Yeah. So this is the agenda for for today. I'm gonna give some administrative and and and reminding the note well, and then I'll go through all the working groups documents that we have active right now and also individual drafts related to the working group. And then we have Yunjong presenting updates on the digital twin draft. Then we have Bart with Nipc and SDF protocol mapping that are now in working group last call. And then there's gonna be presentation on SDF compact updates from from Karsten, and then we have Valentin presenting a new draft on embedding privacy in in the SDF in SDF documents. Then we have also some time for discussion and any other business. So, yeah, this is a reminder of the ITF policies. It's the note well. You agree to it by entering the room. And if you have further questions or you want to see for more details, just scan the code and or get to the URL and and read through. Okay. So now I'm gonna provide a quick update on the documents that we have here. We have two documents in the working group last call. These are NIPC, which is about providing an interoperable API for reaching and connecting to devices that are not Internet connected. And then we also have the SDF protocol mapping draft with which is ancillary to, NIPC and provides protocol specific, mappings, embeddable in SDF documents, like, for example, targeting, protocols such as, ZigBee and and Bluetooth. And these are the active working group documents. We have the SDF type, link that provides, type for the finding links in SDF documents. And then we have the digital twin, which is an informational draft that shows how to use STF for implementing digital twins. Then we have also the instance information, which is about providing instant instant specific information classes. And then STF mapping, which is now STF supplements, providing mechanism for augmenting STF documents. And then we have also the nonaffordance is describing context for for specific models. Yeah. Then we have one working group document, which is candidate for being adopted in the in the working group, and this is the Sdf compact. And today, custom will give some updates upon that. And then we have two individual drafts. One of the two is is new and is gonna be presented today. It's about embedding privacy in ASDF documents. And the other one is the API translation, which, make use of, SDF documents for translating between sets of APIs. Okay. So this was my, introduction. And now, is Yunjong present, or is it presenting?
[00:06:05] Jungha Hong: Hello. This is Jungha. Will present, but she is not available for right now.
[00:06:12] Ari Keränen: Can can we, delay her presentation? Thank you.
[00:06:16] Lorenzo: Yeah. Thank you, So let me I guess then the well, I guess then, Bart, it's it's you. Yeah. So so and and and you don't have slides. Right? So it's just yeah.
[00:06:35] Bart Stevens: Hello. Yes. Sorry. I don't have slides because Okay. In fact, nothing has changed since the last interim. So both Nipc and SDF protocol mapping in, you know, terms of the authors are final. So we're basically kind of waiting for the last call to complete. Yes. What has happened between the last interim and now is that we had an AI engine implement the the draft or basically from the spec, which was successful. So we we didn't really have to make any changes, based on that. So there's the AI implementation. There's, the there's an open source implementation available for, Bluetooth and ZigBee, and then there's also a kind of a closed source Cisco implementation available for both. And we have an open source kind of sample app as well that, you know, has any app that allows any application developers to kind of code towards the towards the draft to a gateway compatible with the latest latest draft. So I think we're pretty much, you know, kind of ready to move this forward. So it kind
[00:08:00] Ari Keränen: of Yeah.
[00:08:01] Bart Stevens: Depends on you.
[00:08:02] Lorenzo: Yeah. Yeah. Yeah. I'm actually in the yeah. I'm writing the the shipper write up now. I actually had some questions on the IANA considerations. I saw that you were asking for individual registers there, And I was wondering if we somehow should reuse the register group for ASDF or if we should request for a register group.
[00:08:25] Bart Stevens: I think both are. Yeah. I mean, we we did request for a register specifically for the the Yeah. The default or the the error Yeah. Codes and then the protocol mapping Yeah. Yeah. Registries.
[00:08:43] Lorenzo: Yeah. Anyone in the audience having an a suggestion on on this? What is better to do? Because I I had a brief talk with at the the hackathon, and one of the option would be reusing the ASDF, and then you you append. So you prepend to to the registers, but maybe this is yeah. Are.
[00:09:12] Ari Keränen: Hey, Are. Which registries are we now specifically talking about? Nipc. But the Nipc had a bunch of registry. There was the error codes. Yes. Are there extensions to the problem details?
[00:09:27] Bart Stevens: Yeah. They're they're based on the problem details.
[00:09:29] Lorenzo: Yeah. Okay.
[00:09:30] Bart Stevens: But we we decided that we were going to because they're not HTTP problem details. They're NIPC problem details. So we decided on our own registry.
[00:09:38] Ari Keränen: Okay. And so that's specific to the registry we're talking about now?
[00:09:42] Bart Stevens: Yeah. That's specific to NIPC, and then SDF protocol mapping has protocol mapping registries.
[00:09:48] Ari Keränen: Okay. Okay. And I guess that the the that's protocol mapping, that's gonna be SDF registry.
[00:09:54] Bart Stevens: I guess.
[00:09:55] Ari Keränen: Yeah. Because that's an SDF extension. That's kinda Yeah. Natural. Yeah. The problem data, is there a precedent on this, like, some other items? No. Okay. So we are the first ones?
[00:10:06] Bart Stevens: We're the first ones. Yeah.
[00:10:07] Ari Keränen: Okay. Any opinion from the problem details folks, or they say
[00:10:13] Bart Stevens: No. No. We haven't really checked with them. No. Okay. Yeah.
[00:10:17] Ari Keränen: I mean, I I don't have a strong opinion here, but just wondering, like, what's either way is probably fine. Sounds like I mean, it's not an ASDF-sdf specific thing. It's more of a Nipc thing, but then again Correct. Would that be whole Nipc set of registries that we envision, or it's not more more sense to piggyback on existing things. That's probably the Yeah. Consideration. Yes. Yeah. But for yeah. For the problem is I don't have strong opinion. For the other one, would have had, but if it's an ASDF,
[00:10:45] Lorenzo: it makes sense. Thank you, Adi. Yeah.
[00:10:48] Bart Stevens: Okay. Anything any other comments? No?
[00:10:52] Lorenzo: That that was my comment. Alright. So yeah.
[00:10:56] Bart Stevens: So I, yeah, I can for for SDF for the SDF protocol mapping, we can add that to ASDF.
[00:11:04] Lorenzo: Step. Okay. Yeah.
[00:11:04] Bart Stevens: Yeah. And then, Nipc, we can the prob for the problem details, we can start a separate registry then.
[00:11:11] Lorenzo: Yeah. Okay.
[00:11:12] Bart Stevens: Okay. I'll see if we need to do any adaptations on the text for that.
[00:11:16] Lorenzo: Yeah. Okay. Yeah. I I I think there might be some, if I remember correctly, but we can also take this offline.
[00:11:23] Bart Stevens: You can take a look. Yeah. Absolutely. Alright. Yeah. Cool. Thank you.
[00:11:25] Lorenzo: Thank you, Bart. Thank you. Do we have Young John now? Let's see. I don't see her. So maybe we should move forward and invite Valentin. No. Sorry. Kirsten.
[00:11:57] Karsten Bormann: Let me Okay. This is about a draft that I wrote in 2023, and, actually, it's about an implementation I wrote in 2023. And, well, I have been using this implementation a lot because it makes STF files much more readable than than the JSON form. As many people don't know, JSON is not for communication between humans. We have other ways to do that. But JSON is a machine to machine language. And there are a few things you want to fix. And YAML is is one way to to fix that. I didn't want to invent. I want to minimize the invention. So I just used YAML as the basis for a compact representation of Sdf. You're probably aware that there are a lot of of languages out there that have compact representations added to them. So the most prominent example is probably relax NG, which is notated in XML. So it's also close to non readable. And it's they have defined a compact notation, and it's crystal clear, beautiful, wonderful. I'm not quite arranging this level of perfection here. But again, YAML does most of the work. And the other two things that that always create a lot of syntactic noise are the the flags for readable, writable, and so on. And you you can see here that there are flags like the RWX flags, you know, from Unix. So it's it's very, very quick to see what what's going on there. So this particular is read only. So you can read it and you can observe it. So the r and o flags are set, but the writable is not set because it measures the the pedaling speed of a pedal user, pedal bike user. And, of course, you cannot write this. And the other thing is the the data model expression. SDF uses notation inspired from from JSON schema. And this is just a compact notation, and, obviously, CDDL is a compact form of that. So this is being converted between CDL and the the way that this is written in in JSON schema snippets. Now interestingly, there is a JSON schema working group now at the IETf, so there there may be a little bit of of communication going on between this working group and the JSON schema working group at some point. But I think this is not going to change fundamentally what's going on there. So my plan right now is to make sure that this the the open source tool behind this is published. So it's I cannot say it's an open source tool because it's not open source yet, but that will happen within autumn. And then maybe get a few comments from people who use the tool, do a next revision of this, and and ask for working with option.
[00:15:19] Lorenzo: Yeah. I mean, the document is already candidate and I
[00:15:25] Karsten Bormann: Right. We we are planning to I I think it's not not nice to ask for adoption while while the cat is still in the bag.
[00:15:31] Lorenzo: No. No. Yeah. But that is this is clearly very useful. Yeah, we'll we'll make it working with documents soon. Thank you, Karsten. Are there any questions on the Sdf- compact here? Okay. Then then I I move on and I see that Yunjong is actually online. Are you ready to present, Yunjong?
[00:16:00] Yunjong: Chairman, do you hear me?
[00:16:02] Lorenzo: Yes. Just let me load yours you you don't have slides. Right? Okay. Yeah.
[00:16:07] Yunjong: How about share slide. My slide, please. Share my slide.
[00:16:15] Lorenzo: Uh-huh. Okay. So you want to share the screen. Yeah. Okay.
[00:16:17] Yunjong: Okay. Thank you.
[00:16:25] Lorenzo: Just a second.
[00:16:51] Yunjong: Firstly, I'm I'm sorry for letting the late I'm I'm sorry for my late because I'm joining another meeting in Geneva.
[00:17:02] Lorenzo: Yes. You you are busy on standardization. Thanks for making the time. I'm actually having trouble giving the sharing.
[00:17:12] Karsten Bormann: Please request. Ah,
[00:17:14] Lorenzo: okay. So okay. They tell me that you have to request it. Can you do that? So I approve it. There's a yeah. Yeah. The buttons below the track There's an icon at the bottom. Yeah.
[00:17:31] Bart Stevens: Oh, dear.
[00:17:31] Lorenzo: Yep. So when you click that, like oh, yes. Exactly. It went away. Can you request it again?
[00:17:49] Yunjong: Okay.
[00:17:53] Lorenzo: Okay. It should it it's loading.
[00:17:56] Yunjong: Yeah. Okay.
[00:17:57] Lorenzo: Yep. Yeah. It's it's already approved. It's just maybe she has to give some permission to the OS. Yes. Whenever you want
[00:18:19] Yunjong: the slide? Can you show the slide?
[00:18:24] Lorenzo: We could. No. We can't anymore. Think it just crashed. Can you request the share screen screen again screen sharing again?
[00:18:36] Yunjong: K. I'm sorry for this trouble.
[00:18:43] Lorenzo: Okay. Now I approved. Yeah. We see your PowerPoint now?
[00:19:07] Yunjong: Oh, yes. Can you see the PowerPoint?
[00:19:11] Lorenzo: Yes. Yes.
[00:19:12] Yunjong: Oh, okay. Thank you, everyone. Thank you, and hello, everyone. I'm from. Today, I'd like to provide a brief follow-up update on our drift data tree. This presentation focus on the discussion from the previous meeting, particularly, Ari's comment regarding the pro protocol related text. I also briefly explained our plan to prepare the document for working room last call in November meeting. The purpose of this slide follow-up updates. The purpose of this presentation is to summarize the current status of the document after the previous ASDF discussion. Firstly, we would like to address comment and clarify the intention of the protocol related text. And the document does not attempt to define a new protocol mapping mechanism or specify which communication protocol must be used for a data twin. Instead, the protocol considerations are intended to provide general guidance on how on a a step model may be connected to runtime communication mechanisms when it is used for an operational data twin. In the previous version, our main focus was adding protocol considerations for operational data twins. Our current focus is to clarify the scope of this material and determine whether the document is ready for final working group review. Our target is to initiate WG WGLC in November meeting. Draft two four introduces protocol considerations in section five. However, on I already pointed out during the previous meeting, this protocol should be understood only as an examples as examples of possible communication protocols. They are not intended to represent the protocols formerly supported or defined by the current SF protocol mapping work. In particular, the current SF protocol mapping document mainly focuses on BLE and GP. Therefore, we will revise the text to make the this distinction clearer. The main purpose of this the section is to explain the conceptual relationship among three elements, the SF model, a protocol binding, and and on operational digital twin. The SIF model describes the structure, property, actions, and events of a physical or digital entity. A protocol binding may then connect these model elements to an actual runtime communication mechanism. Through this binding, the step based dis discussion can be used in the operation and synchronization of a. In addition to the protocol considerations, are so also included arterial corrections and sentence refinements. Before initiating WJLC, we plan to review the document in four areas. The first area is the scope. The second is an example examples. The third area is terminology. The fourth area is working group review. The first area is in the first area, we will confirm that the document remains focused on aesthetic modeling for data train and does not expand too far into protocol specifications or implementation requirements. The second, we will review the protocol related examples and clearly identify them as illustrative examples rather than normative protocol requirements. And the third, we will align the working with wording with the with the existing ASDF and SDF terminology and over the unnecessary overspecification. And first firstly, after addressing the comments, we will note on updated version and ask the working group less court to conduct a final review. Our current place plan to unload and present the revised document and then initiate working group last call in November meeting. Of course, this schedule depends on resolving the remaining comments and confirming that the the uploaded text is sufficiently clear. Next step. Our next step is to revise the protocol installation text based on the feedback from the previous meeting. When the revised text is ready, we will upload a new new version of the draft, and then we will ask the working last four in November meeting. Please also let us know if any additional clarification is needed before working on Rasko. Thank you very much.
[00:24:44] Lorenzo: Thank you, Yunjong. Any comments here from the audience? Ari, please.
[00:24:58] Ari Keränen: Ari, Carolina. I guess there was a strong dependence between this draft and the nonaffordance draft. I was wondering what's the status of a non of what we used to call nonaffordance draft? That that will be a key element for modeling some of the digital twin parts.
[00:25:21] Lorenzo: I guess we have in the meeting, so Mhmm. Perhaps she's best for answering this.
[00:25:33] Jungha Hong: Thank you, Ari. This is Jungha. Let me response to you. The nonaffordance, the draft of the nonaffordance is
[00:25:45] Ari Keränen: not maturing of yet. So we are planning to update
[00:25:53] Jungha Hong: maybe two or three times more.
[00:26:00] Ari Keränen: Mhmm. Yeah. Because what I was thinking probably would be a very good exercise to try to use the nonaffordance information in the kind of within the guidance of the digital twin draft. And then, the next question would be like, you had a chance to talk with some people who have been doing kind of digital twin modeling and kind of trying to use this draft as a guidance and see how it works? Or I I know you're you're involved in this other standardization on the GitHub Twins. Maybe there are some people actually actively using it and getting feedback from them that, like, does it cover the kind of things they would expect to find in a guidance document?
[00:26:46] Yunjong: Actually, I'm in Geneva meeting, SG11. So I may I'm developing standard in SG 11 and IEEE 2888. So there are so many data twin groups in other standard groups. So in SG 11 meet in a in a SG 11 document and the I three p twenty eight eight document, I have the I have some contents for the data twin development procedure, things like that for carbon emission management. You see the answer for you?
[00:27:27] Ari Keränen: Mhmm. Okay. So so you have had the dialogue in the s g eleven group people. So I was wondering, have they had a chance also others to kinda check this out, the draft, to make sure that, you know, we get the broader review on, like, are these the things that they would expect to find there? But if you have it, that that's that's awesome. But if you have more chance with more of that in the other groups, I will possibly create and hear hear their feedback. Are we are we doing the right things in the draft, Give the right information to be able to use Sdf efficiently. Because I can imagine there are things like terminology and others that are you know, you need to be able to represent in a way that is consumable by by those doing the digital twins.
[00:28:10] Yunjong: So if the documents are published, then I will share my documents to you.
[00:28:20] Ari Keränen: Okay. Thanks.
[00:28:21] Yunjong: Thank you.
[00:28:23] Lorenzo: Yep. Thank you. And and and I will discuss with Michael about the working group last call. But, yeah, we will provide reviews for the for the document for sure. I have actually one request. I saw that the draft is not on on on the GitHub. So if you can add it.
[00:28:42] Yunjong: There is no no repository for digital twin, and there is only nonaffordance. Can you make the repository for digital twin in GitHub?
[00:28:53] Lorenzo: Yes. I'll I'll I'll create a new one and then contact you for, yeah, for you to up upload the the draft there.
[00:29:01] Yunjong: Okay. Thank you.
[00:29:02] Lorenzo: Okay. Okay. Yeah. Thanks. Yeah. And and I'll contact you when I'm when I'm ready. Okay. More questions on on the digital twin draft? Otherwise, we move forward. Okay. Then I guess we move forward, and I guess we have Valentin. Hello. Just a second. Let me share the slides. Okay. Hello. Hello.
[00:29:37] Valentin Todor: Can hear me?
[00:29:39] Lorenzo: Yeah.
[00:29:40] Valentin Todor: Yeah. Great. Hello. My name is Valentin Todor. I'm, I'm a researcher at Ericsson Research in Sweden. This is my first IATF meeting, and this is my first presentation at the IATF meeting. So bear up with me with this one. Okay. So today today, I'll I'll try to walk you through a proposal for a private extensions for SDF proxy operations. And this proposal is authored by Martina, Ari, and myself. And the core aspect or the core problem that were targeted here is that an SDF proxy has to understand the schema in order to translate between the SDF APIs and the device ecosystem, but the schema itself can reveal sensitive information. So today, I'm going to try to explain what could possibly leak or being heard from the schema, why payload encryption alone is not is not a solution, and how a proposed SDF privacy quality will let the proxy keep translating while the proxy learns as less as possible about the device and the interaction. And before continuing to the next slide, I also need to mention that there is an IPR disclosure filed on the draft and more information can be found on the data tracker. And now I don't know. Do I need to change the slides or do you change the slides, Lorenzo?
[00:31:17] Lorenzo: I'll give you control. Just a second.
[00:31:19] Valentin Todor: Thank you. Or I need to request No. No. No.
[00:31:25] Lorenzo: No. From
[00:31:26] Valentin Todor: my side. No. No.
[00:31:27] Lorenzo: You you should be good to go now.
[00:31:29] Valentin Todor: Okay. Great. So let's see. Yes. Great. So first, let's let's talk a little bit about the trust model. And in in some scenarios or majority of scenarios, the proxy might not be a part of the same trust domain as the application and the device. As the proxy could be a third party gateway, a cloud translator, maybe a shared hub, or a box sitting on the edge. And in all of these cases, it could be minimized what the proxy learns about, the sensitive interactions between the application and the device. And in some cases, the proxy actually wants to learn as less as possible, about these interactions. And the endpoint, the application, and the device have their own trust relationship or may have their own trust relationship. And the proxy itself needs only to translate. It does not need to become a party in this underlying semantic exchange. And if the schema exposure is left unaddressed, there could be some possible privacy risks. And a proxy operator or someone with access to the proxy operator could be able to, for example, profile health conditions, home occupancy, or or different habits depending on the on the interactions exchange. Similarly, it could reveal device inventory. It could identify the known models and map them to known vulnerabilities. And it could also create a regulatory exposure where sensitive categories are inferable from metadata. And this could happen even before any measurement or any any data is actually read or exchanged. So the design here is is quite simple or the core of the design is quite simple. We should let the proxy keep doing its job, but without learning what sensitive interactions ask through it. And starting with the with the basic motivation, I don't think I need to to stress it out. So asdf is useful because it describes these affordances in an ecosystem dependent way. And uses that is and a proxy could use the description provided by a SDF to translate the the the calls into something that is ecosystem specific. But the privacy issues or where the privacy should start is that the proxy normally needs these Sdf definitions and the mapping in plain text in order to understand the translations and and what it needs to do. And even if the application and the device use end to end encryption for the payload values, the proxy can still see the surrounding schema because this information is used for for routing and translating the the different calls. So the distinction here is that if the payload confidentiality hides the measured value, the the actual question that is being asked is in in plain, is not hidden. And similarly, the device model that is being addressed or the semantics around the value are also in in plain. So by this proposal or by this this is nice to have Sdf privacy property, we try to address this gap. And on this slide are a little bit a couple more examples of what could be actually exposed or or revealed. And for example, from the different names that are used, for example, if you have a heart sensor or if you have something called a glucose level or a door lock or or a baby monitor or infant monitor, this could immediately reveal what's the purpose of the device. And this metadata that is human readable or AI agent readable can expose labels, descriptions, units, manufacturers, and and the information about the model. And even if the obvious names would be removed, the value semantics will will still reveal also a lot of information. So types, ranges, and enumerations can make the meanings inferable. So for example, if you have a numeric range between zero and two fifty for something called simply rate, it could suggest a heart rate monitor. And there's also a structural fingerprint in the definition. And the number and the combination of properties and actions and events can identify or can help identify known devices. And the proxy by observing or by triggering this interaction or yeah. By observing this interaction patterns, which affordances are invoked when and how often can correlate those patterns with a visible schema. So I stress I I I said this, but I stress again, the takeaway is that encryption of the payload value is necessary or could be necessary in some scenarios, but it might not be enough to hide the the interaction semantics. And this is the simple architecture here. Basically, this is how Sdf works, but I'm going to explain how how the privacy extension is going to to be added here. So the we have an application on the left side and the the application uses an SCF based API to an SCF proxy, which could be a third party. And this proxy translates towards the ecosystem specific device type, the the actual commands that extend. And in the baseline model, so without the the private extension, the Sdf, the the proxy sees these Sdf definitions and the ecosystem mapping. And in the privacy enhancing, version or model, the application preprocesses the Sdf and the mapping before the proxy uses them. And the proxy still performs or could perform its normal translation functions, but it operates on privacy preserving names and definitions instead of the original definitions. And another key point here is that the actual setup of this and the data retrieval could be performed by different entities. And this actually this flexibility could actually matter for for real deployments. So the device remains constrained and ecosystem specific while the proxy can be untrusted or less trusted or partially trusted. And in in some of these deployments, the proxy may also contain a trusted execution environment, but I'm going to come back to that later on in in one of the slides. So the proposed mechanism here is expressed through a new quality which is called Sdf privacy. It's here on the lower side of the of this slide. And this Sdf privacy quality could be placed inside an Sdf object or an Sdf thing. And we have a sensitivity field which is set to true here. And this sensitivity field marks whatever the specific grouping, the object or the thing is sensitive. And the sensitive definitions here identify the specific definitions that need to be protected. And if the field exists, so it's true, and the sensitive definitions is missing, it could be imply implied that everything under that group needs to be protected. And then we have something called a privacy algorithm that identifies which kind of of transformations or privacy protection needs to be applied. And we have another one which is called privacy algorithm parameters which provides algorithm specific controls. So for example, it it said if the metadata should be removed or what kind of key should be used or what kind of parameter should be used for for the the algorithm or the method that is supplied. So if we take, the example here, we have, this is extracted from a a heart monitor. So we have a heart rate, calibrate max rate, and min rate, which are marked for protection. And we we have an algorithm here which is called obfuscate names version one. And also remove metadata which is set to true. And this means that in this preprocessing step, privacy preprocessing step, needs to transform the semantic names and needs to remove the human or AI agent readable descriptions and preserve only what the proxy needs for this translation. And one thing here that is important is that this design principle or or the design principle here is that privacy preserving this privacy preserving the recipe or policy will travel with the SCF model. So as sensitive parts are handled consistently rather than being left at the at the the wheel or the behavior of the of an ad hoc proxy. And here is the the original SDF definition for this health center or for the heart center. And I already mentioned that we have this heart rate, max rate, min rate, and and this kind of actions, the calibrate action. And I'm going to now switch to its privacy preserving output. On the previous side, I could could have stressed what each of of of those qualities or or theses could reveal as a sensitive, I think that is clear. So focusing here on the on the privacy preserving output, we have replaced or or the method has replaced the the namespace. The object name is changed to a non semantic identifier, and the property and data names are also obfuscated. Human readable qualities such as descriptions were removed. And what is kept here is the data type. So the proxy will still know what type of information it is so it needs to translate the values correctly. Two new affordances, padding affordances have been introduced here, four and five, two four and two five here. This would prevent or make correlation attacks or inference harder. And this kind of padding does not completely eliminate traffic analysis, but it could reduce the direct correspondence between the original set of affordances that we have in these health centers and this privacy preserving output. And by using this transformation, the proxy can still process the this this model, this transform model. It is a structure that it understands and and could translate. But original names that that heart sensors or current heart rate or or the other the other actions that produce we have there are are hidden or or not directly accessible to the prop to the proxy. And on the other side, the device, by receiving some set of material before, it could actually map these transformations or these transformed identifiers back to the real affordances. So the output here or the effect is not about hiding everything from everyone, but it's about giving the proxy only the minimum set of information that is needed for each translation role. And we envision two operation modes here. One is without the trusted execution environment. So in this case, the proxy translates the privacy preserving SDF calls into some privacy preserving ecosystem characteristics and is the job of the device at its end to map those identifiers back using some material received during setup. And if necessary, the mapping can be rotated by rerunning this this this setup. And in this mode, without a trusted execution environment, the proxy is kept simple and we avoid trusting it with plain text semantics. But still this requires good a good setup a good setup process and confidentiality between the application and the device. Then we have a second operation mode where we actually have a trusted execution environment or an enclave at the at the proxy site. And this enclave the other setup can actually hold the plain text SDF and perform the actual translations inside this protected environment. And then on the other side, we can have a tunneled channel to the device, and that would prevent the the less trusted part of the proxy from seeing these ecosystem characteristics. So in this mode, plain text ecosystem characteristics are acceptable or accepted inside this tunnel, but the design now depends a lot on the trusted execution environment integrity and the establishment of the tunnel. And in both of these modes, sensitive for this is that are non sensitive can continue to operate normally. So we have also this kind of flexibility that lets deployments, different deployments protect only the interactions that that require protection or require protection in that specific scenario. We have identified a number of open questions here. I'm just putting them here. Maybe they're good for the discussion or to think about them. So the first one is that the approach depends a lot on the secrecy of the privacy algorithm key or or material or the equivalent setup. And if this material is exposed to the proxy, the semantic protection is weakened or even lost. Second, the padding would help only to a limited extent. It can make simple correlations harder, but it does not fully solve traffic analysis. Frequency of request timings, call sequences might still leak. So depending on the scenarios, depending on where these Sdf translations are used, how sensitive they are, it would be nice to study or to find solutions for stronger padding, rotation strategies, patching. But while doing this, still keeping this balance between the between privacy and utility because we're still talking here about constrained devices. Then in the operation mode without the trusted execution environment, the setup must be protected end to end between the application and the device. And in the trusted execution environment operation mode, the actual security argument shifts to more towards this trusted security environment, integrity at station, and the the tunnel that is set up between the TEE and the device on the other side. So what we're trying to propose here is or we think it's a practical starting point, of course, by by taking into account these these these limitations, but also the the benefits of it. So we want to reduce the the schema disclosure while keeping the proxy translation feasible. This is the first step. And then later on we need to refine the security properties as the ecosystem will gain implementation experience. So this is my last slide, and the main takeaway here is that as the proxy privacy is not only about encrypted payload values, and the schema itself can also reveal device purposes, sensitive categories, and also interaction intent. This proposed SDF privacy quality will give applications and devices a way to transform sensitive definitions before this proxy systems while still allowing the proxy to translate. And, at least at this moment, we envision, or we see two operation, modes. One, using this privacy preserving map mappings at both ends of the application and the device. So without the help of trusted execution environment and the other one with the help of trusted execution environment running at the proxy site. And, each of them have these different, trust and setup requirements. With this, I would like to thank you for your patience and attention and we can move to questions.
[00:51:05] Lorenzo: Thank you, Valentin. We have a question from Daniel. Go ahead.
[00:51:08] Daniel: Yes. Daniel Smolon speaking. So I wanna start by just saying that I think that this is actually really great because it solves a problem that I have in one of my drafts. And so I think we we should probably chat about this in more detail. But for the session, I wanted to raise a few criticisms actually. The first being that I think that your example is is good and illustrative because it shows clearly the objective of trying to obfuscate the actual metadata schema. But I think that you're missing a golden opportunity here, which is to be able to apply potentially, you know, privacy preserving technologies, privacy preserving algorithms on the actual values themselves. Right? It seems like what you're doing here is you're saying, okay. Look. You know, those values are just gonna be secret. But because they're secret, we also have to pseudonymize the the metadata, and then that's gonna give us privacy. But, really, what would be even better is if, for example, with your your, you know, heart rate monitoring, you could apply differential privacy to that and then also pseudonymize the metadata field. This really, I think, would be a tremendous benefit, for for this kind of of, of architecture, especially because there's so many, you know, new technologies that are becoming available where you can, perform these types of translations and transformations on the data within an untrusted, execution environment. Right? So, again, I'm not advocating for something like, say, fully homomorphic encryption, right, where then this may still yet be useful because even though the values may be hidden, you might still need to preserve information about the the schema. I'm actually advocating for other privacy enhancing technologies that then you could, you know, use your system as a way of bridging the gap, for downstream processing nodes or what have you, to know what the expectations are for the data that they're receiving. Right? Which is actually a very, very difficult problem to solve because if you just declare that as part of the data type, then you lose all the other essential information about how that privacy enhancing technology may have been parameterized. Right? So, you know, again, we we can talk more about this offline, but I just wanted to really, like, say bravo. This is excellent work. But I think you gotta go even further.
[00:53:28] Valentin Todor: Thanks Thank for a lot the comment. Very good comment. And I I I agree with you. I completely agree with you with this. In my mind, we we we we have these two sides on how you can approach this. One, as you mentioned, is also targeting the privacy protection of the values themselves and extending these two two methods for themselves. And the other one is actually what you can infer by the metadata. So in this draft, we we have focused only on this part, on the metadata. Because then the processing itself or or how the data are processed, so you mentioned differential privacy, then you would need to do some sort of of of processing at the at the proxy level, which might or might not happen depending on what kind of applications you you have. You might need to have some aggregations. So I I agree with you, but I I see that as a as a a little bit of a different field that could be approached. Maybe we can address it into this draft, but I I don't know. Maybe it's better to keep them separately, one on the metadata, the other one on the actual methods that are that
[00:54:44] Daniel: are I would argue that the the problem is one in the same. Right? So whether the what processing takes place, what privacy enhancing technology is definitely a separate issue. Right? Whether it's differential privacy or some other anonymity thing, whatever, doesn't really matter. But I think the point is that you still need to preserve in the metadata that the values that are coming through have been transformed through that mechanism. And so that's where the problem kind of lies. And you do face that problem actually because you're obfuscating metadata fields in order to prevent an observer from determining what the metadata is saying about the overall data. Right? So I think, actually, you really do take on that problem whether you like it or not, unfortunately. But you're well positioned to solve it because you can apply all sorts of different transformations on that as well. Right? So, again, the data is still secret. You can do whatever transformation. That's fine. But that means that you've now got a golden opportunity to then tag the data and say, yes. Actually, we did do something to this, but we don't want anybody to know that. Mhmm. Right? Or at the very least, we wanna hide that from anyone who we don't want to share that particular piece of the metadata with. So yeah.
[00:55:52] Valentin Todor: Mhmm. Thanks.
[00:55:59] Bart Stevens: Hello, Bart from Cisco. I was a little confused with the term proxy, which I thought was something that proxies an SDF model versus a gateway which kind of translates it into a specific ecosystem call. Does this apply to both or or just one of the
[00:56:24] Valentin Todor: I I will say this applies wherever you need to translate the the the SDF definitions via consistent characteristics.
[00:56:35] Bart Stevens: Okay. So we've and and, like so it could be a Nipc gateway. Yeah. So we we typically have used the term gateway for that. So I don't know if that
[00:56:45] Lorenzo: I think this is a deployment problem. Valentin might confirm that. It's do you make this translation happen, basically?
[00:56:56] Valentin Todor: Probably, it is. Yes. I would need to to to look more into it.
[00:57:01] Lorenzo: And and then considering that you are targeting also constrained devices, maybe Nipc gateway could host part of that.
[00:57:10] Bart Stevens: Okay. And then the the second question is the application could also just supply a smaller model to a proxy or a gateway with just the let's say, a health care health device has a lot of functions and the gateway only has to translate, for example, heart rate, you don't have to send the entire SDF model. And you could also obfuscate that, property and just name it differently. So so do you, the question is is is this really required? Because the application could just send pieces of the model, for example.
[00:57:56] Valentin Todor: You mean separate perform minimization only by or simply by dividing the model in the sensitive and non sensitive parts and then using only what is needed at the gateway.
[00:58:08] Bart Stevens: Yeah. And then obfuscate the names of the the sensitive part.
[00:58:14] Valentin Todor: Yes. I mean, this this solution could be used to do that as well to the to to do that.
[00:58:20] Lorenzo: I guess we might need some changes also in or some extension in to do that. Right? Otherwise, the let's say, let's use the new c gateway then it will know how to append the sensitive part to the model. Right?
[00:58:40] Bart Stevens: Yeah. But you could use two different models. Right?
[00:58:42] Lorenzo: Yeah. Yeah. Okay. Yeah. Yeah. Or at least when you see certain model, then you just ship the full one Yeah. To whoever is allowed to to see that. To see the full one. Yeah. Yeah. That's a very good point.
[00:58:56] Bart Stevens: Thank you.
[00:58:57] Lorenzo: Yeah. I don't know if Valentin has more insight on that or we have a okay. We have another question, Adi.
[00:59:02] Ari Keränen: Yeah. Adi, can I just comment on on on BART? Yeah. Exactly. You could do that what you said. This just gives a standardized way to imply how you would do it. So you could totally do that application. That's definitely one way to do it. You could have a second or third or fourth party doing it for you. But that's exactly the idea that you would if some information is not needed, how do we market in the STF in a standard way? So yes. Sorry.
[00:59:25] Bart Stevens: Yeah. But but different gateways could need access to different parts of the
[00:59:30] Ari Keränen: That's a very good point. So may maybe we actually need a gateway specific or let's say and it's actually not only gateways. This could be, you know, let's say, ALG or logging entity that you don't wanna reveal everything. Let's say, any use case where you want to give the SDF definitions to some third party that doesn't need to have all the details, you could use this. But maybe you should actually, you know, make it a then that kinda application specific so you could have more than one of these privacy blocks. That's maybe a good solution. Thanks.
[01:00:01] Daniel: Daniel? This is Daniel Swan. I'll keep this brief. I do actually just want to address that same comment as as well, and I want to very strongly discourage doing that. And the reason why is because the more of this metadata that you reveal in this non sensitive context, the more likely it is that then you can infer the sensitive attributes. And so this completely defeats the whole purpose of the privacy scheme. Right? So, really, ideally, you would want to only send in, I guess, in the clear, so to speak, the most minimal possible attributes you can in order to ensure the coordination between these various nodes and everything else you would want to obfuscate at the very minimum. Otherwise, you really are opening yourself up to traffic analysis, and it becomes trivial to then infer what these other attributes are.
[01:00:47] Valentin Todor: Yeah. Exactly. That that opens the gates to to to Mosaic privacy attacks. Right? You you gather different pieces from different gateways, and then you put together the the big model. Yeah.
[01:01:05] Lorenzo: Do we have any more questions?
[01:01:17] Niklas Widell: Nick, Erickson. So years ago in this group or before this group existed, we discussed the kind of access control to SDF objects. And I don't think we ever developed that further. It was basically like ways to filter information coming out of an object. That looks I'm not saying this is not exactly the same as privacy, clearly not, but it's solving a different slightly different problem. But maybe the idea of having some kind of filter on top and because you want to show some information to some parties and some information to other parties. I need to dig through my mail source if we ever documented that, but it might be because I think this it clearly addresses a larger problem of sort of sharing information and who can share what, and you mentioned logging and so on. So yes. But thank you for doing this work and bringing it to them. Thank you.
[01:02:12] Bart Stevens: Karsten?
[01:02:17] Karsten Bormann: Karsten, moment. Yeah. Adding authorization information, which I think is the general name for this, to
[01:02:27] Valentin Todor: the
[01:02:27] Karsten Bormann: model. Of course, what you exactly want to do there depends on who is supposed to act on this information. And you can talk about the the safe description of of a device without talking about who is allowed to to do what, when, without any giving out any information about that. And this is what Sdf does today. And as soon as you go into date detail, you have to consider who would consume this information. And is that actually the right entity to to actually implement the authorization policy that that you are doing. So I think that this is a pretty interesting. Working with this would be a pretty interesting extension.
[01:03:32] Lorenzo: More questions? Okay. Then, thank you, Valentin, for the presentation and for the contribution. Let's see some privacy work in ASDF.
[01:03:47] Valentin Todor: Thanks a lot for having me.
[01:03:48] Lorenzo: Yep. Thank you. So now, we allocated some time for discussion. Is there anything that, we should bring up in the working group to discuss? I didn't hear that.
[01:04:08] Eliot Lear: Lunch options.
[01:04:09] Lorenzo: Okay. Yeah.
[01:04:12] Ari Keränen: Yeah. Sorry to be in between you and the lunch. Yeah. I mean, one thing that we just discussed with Bart up right before the session, what might be a useful thing to have in this group is a kind of a document describing how to use STF to model things. I mean, we have this coming for digital twins, but then we have, like, the Nipc case and others. And, I mean, it's it's of course, we know how to do stuff, but then it's a lot of institutional knowledge that is not written down anywhere.
[01:04:37] Lorenzo: Yeah.
[01:04:37] Ari Keränen: So based on the Nipc experience and others might be useful thing to write something, kinda guide informational guidance document, how to use use SDF. So anyone interested on that kind of work? You know? That would be Yeah.
[01:04:51] Lorenzo: Just jump in. Sorry? Something
[01:04:56] Ari Keränen: faster.
[01:04:58] Eliot Lear: This is Elliot. Sorry. I I didn't click the thing in the thing. So I actually think, Adi, that's not a document. That's a series of demo programs.
[01:05:09] Ari Keränen: Could be.
[01:05:10] Eliot Lear: And, like, people should be saying, here's how you can control a light. Here's how you can control look at this cool little thing that I vibe coded up in ten minutes. And and actually count the count the minutes that it takes to do. Right? And especially if you're using, the Nipc libraries. Right? You just you you say to Claude, hey. Go and use the Nipc libraries and and and code me up something that does x, y, or z. Or you don't wanna use the Nipc libraries, you wanna use something that Carson's or whatever the case may be. Like, right now, the the how to use is best demonstrated through, like, little snippets of code. Actually having a little website that that points to all that stuff, like a .io website would be sort of cool.
[01:05:58] Ari Keränen: So SDF IO. Yeah.
[01:06:01] Lorenzo: I'll check Namecheap now.
[01:06:05] Daniel: So, yeah, I'm I'm strong this is Daniel Swalen speaking. I'm strongly in support of this idea, in particular because it would really help benefit the collaboration with other groups that are trying to do stuff with stuff like SDF, but can't quite figure out exactly how. You know? So for for the for the work that I've done, which is related to specifying privacy preferences, I've kinda had to come up with my own sort of taxonomy draft, and, you know, there were certain properties about SDF that I couldn't really figure out how to shoehorn in and whether I was gonna express it properly and so on. And I could again see obvious, things like the privacy extension we just discussed is valuable for for my work. But, you know, that doesn't really solve the core problem of, like, well, is SDF the right tool for the job to begin with. Right? So it'd be real it would really make it more accessible for folks like me. You know, I'm looking for something to build on. I'd really rather not have to do the dual lift of introducing one piece and then also this whole other language as well. Right? So, yeah, this would be good.
[01:07:04] Lorenzo: Thanks for that. I yep. I I think we we have been discussing with the group this for some time, and I guess it's time that we act on that probably. So but, yeah, I leave the word to Eric. Yeah.
[01:07:16] Ari Keränen: Exactly. And I think this is a really good discussion, like, is the right form for it? So Yeah. Very good suggestions here. And, like, maybe, you know, it's a Wiki page that points to right sources, etcetera. So maybe that's something we can discuss over lunch.
[01:07:32] Lorenzo: Yes. Let let let's do so. More things to discuss. Okay. Just maybe one one note. We should be planning for an interim meeting maybe a month from now. I'll send an email over the mailing list to to plan that. Usually, we've been doing this on on Wednesdays, but we can we can check that. I'll send out an email. Okay. So if there are no any other businesses, I guess we can end it here. Thank you all for for joining, for engaging, and thanks for your contributions. Yep. Thank you. Yep.