LC: NIPC and protocol mappings in WG last call. Five active I-Ds (link
type digital twin, instance info, mapping, non-affordance). SDF compact
as candidate for adoption. Two individual drats: API translation and
proxy privacy.
BB: Both NIPC and protocol mapping from author PoV done. Since last
interim had AI agent implementing the draf from the spec. Was succesful.
Now have the AI's implemention, open source for bluetooth and Zigbee,
and closed source Cisco implmentation. Also open source sample app that
allows to code gateway compatible to lastest drafts. Ready to move
forward.
LC: writing writeup now. Some questions on registries. Should use the
ASDF registry or request a NIPC registry.
BB: for error codes requested NIPC registry.
AK: which registries specifically?
BB: problem details and sdfMapping extensions. Latter would be SDF
registry. Former potentially new.
AK: any precedents for the problem detail extensions?
BB: not yet
AK: then sounds OK either way, but could check from problem details
folks for opinions
CB: Draft proposing format more useful for humans. JSON is not very
human-friendly. This uses YAML as basis. JSON schema WG now that might
need some coordination. Plan to open source implementation within
autumn. Plan to get some comments and ask for WG adoption.
LC: draft is candidate adoption; clearly useful
HL: update on digital twin draft. Addressing comments on the protocol
related text. Targeting WGLC in Nov 2026.
AK: what's status of non-affordance draft? would be useful to look at
these together for DT modeling
JH: still needs a few more rounds of updates
AK: have you had a chance to get comments from people doing DT modeling
on the draft?
HL: engaged in the SG11 standardization
VT: Addressing the issue that SDF schema can reveal sensitive
information and how new extension can help proxy translating while
minimizing information shared. In some cases proxy and applications in
different trust domain so want to avoid sharing too much information.
VT: suggesting SDF extension that can indicate which definitions should
be covered and parameters for privacy preserving algorithm. For example,
SDF definition names can be obfuscated and human-readable descriptions
dropped.
VT: Some open questions. Depends on secrecy of privacy-algo key. Oadding
provides only limited extent (how to approve) nice to have stronger
mechanisms while still keeping balance between privacy and utility. TEE
mapping setup needs e2e confidentiality.
VT:
DS: this is great; solves a problem that have in one of my drafts.
Shoudl chat about this in more detail. Some criticism: example shows
objective to obfuscate, but missing golden opportunity to apply privacy
tech on the values themselves. E.g., differential privacy on heart rate
data. Tremendeous benefits there. Transformations in untrusted execution
environment. Can talk more offline.
VT: thanks, agree. Have two sides: targeting the values themselves, and
what can be inferred on metadata. Here only focus on latter since how
data is processed requires processing at proxy level -- depending on
application. Could maybe be addressed in this draft or could be kept
separate.
DS: would argue the problem is one and the same. Well positioned to
solve this with transformations. Data is secrect but have golden
opportunity to tag that did operations.
BB: confused with proxy vs gateway; does this apply to both?
VT: whenever trying to translate to ecosystem chars
BB: could be NIPC gateway.
LC: deployment problem; where you do the translation
VT: probably yes
BB: application could also just supply smaller model to proxy or
gateway. Don't have to send entire SDF model. Application could send
only pieces of model.
VT: yes, this could be used for that as well.
LC: would need extensions to SDF also for that
BB: could use two different models
AK: yes, this extension would be standard way to signal that. And not
only for gateways but also for example ALGs and logging entities. Could
perhaps benefit from having multiple privacy blocks per use.
DS: want to discourage that; more metadata revealed in senstive context
more risk revealing. In the clear would want to send minimum amount of
data.
NW: years ago discussed ACL for SDF objects. Ways to filter information
coming from objects but maybe some filter on top depending what
information to share is relevant here.
CB: adding authorization information to model; depends who is supposed
to act on the information. Can talk about self description of device
without talking about who is allowed to do what. As soon as go to
details will have to consider who would consume the information and is
that right entity to implement authorization. Working on this would be
interesting extension.
AK: have been offline discussions that having a document to describe how
to use SDF to model would be useful
EL: instead of document, could be set of projects we point to. Have
website like sdf.io for this
DS: Supporting idea, sounds useful
LC: interim meetings to be planned