Re: Securing Actions and Procedures

Christoph,
All,

With respect to JSON-LD metadata, inline or URL-addressed resources could be knowledge graphs capable of being merged together such that constraints (e.g., SHACL, SPARQL) could be checked to prevent errors and paradoxes in resultant metadata.

A list of user-data resources accessed by a function, for example, could be simply merged together from two or more inline or URL-referenced (compatible) metadata resources but a value could not be both "true" and "false" as a result of merging two or more (incompatible) metadata resources.

Metadata resources could, alternatively or additionally, specify lists of constraints upon function-call "contexts" provided by runtime environments. Such "contexts" would, as envisioned, include properties or subcomponents including the current "caller" or "invoker". As envisioned, runtime environments would create, represent, and maintain situational function-call "contexts" and functions' security metadata would express that certain constraints must hold upon these for the functions to be invokable. Otherwise, a structured validation report would be included in an error message.


?context rdf:type sec:FunctionCallContext .
?context sec:hasCaller ?caller .
?caller  sec:hasPermission sec:security-category-1 .


So, inline or URL-referenced JSON-LD metadata resources capable of being merged together could be: (1) knowledge graphs, (2) lists of constraints which must hold on a runtime-environment-provided function-call "contexts", (3) both, (4) other...


Best regards,
Adam

P.S.: Also, just as there are source-code "minifiers", tools could prefetch and merge multiple URL-addressed JSON-LD resources together to produce fewer inline metadata instances. That is, developers could create and view functions' metadata as comprehensible combinations of well-known, declarative URLs, and then, as desired, run tools which fetch any referenced resources, merge them together, check constraints on the resulting merged metadata, and generate resultant source code having fewer, or single, inline metadata items per function. Such tools might be useful if one wanted to shave milliseconds off of initializations after rapidly prototyping software...

________________________________
From: Christoph <christoph@christophdorn.com>
Sent: Wednesday, February 25, 2026 7:16 PM
To: Adam Sobieski <adamsobieski@hotmail.com>; public-pm-kr@w3.org <public-pm-kr@w3.org>
Subject: Re: Securing Actions and Procedures

Hi Adam,

The ability to attach multiple resources to the same function is an essential feature to me.

I find the need to tag actions from multiple domain perspectives. This allows for quick and dirty schema additions when working on the edge.

The resources must be completely independent at the attachment layer to allow co-locating any meaning.

I combine these direct attached schemas using higher-order schemas into an ontology/model.

The key takeaway:

1) Attach concrete things first
2) Allow for mapping concrete to more abstract later
3) Abstract can evolve into new concrete things to attach

This is an interactive evolution process that can scale.

I am in the process of using this approach to model my components & APIs visually from all kinds of perspectives.
The beauty is of course building abstract visualization models that ontologies can leverage to render themselves.

Christoph


On Wed, Feb 25, 2026, at 7:02 PM, Adam Sobieski wrote:
Christoph,
All,

Excellent. I hope that the group's discussions, here, in upcoming months, on these topics, can be of use to your project and, optimistically, to some unfolding MCP- and WebMCP-related discussions.

Brainstorming, one could provide inline JSON content or URLs referencing JSON or JSON-LD resources in attributes, annotations, or decorators:

@metadata('{"property": "value"}')
function(...)
{

}

@metadata("https://example.org/security-category-1.json")
function(...)
{

}

That is, content passed to attributes, annotations, or decorators could be, beyond lengthy lists of argument values for parameters, inline JSON or JSON-LD content or URLs referencing such resources.

Inline or referenced resources could be reusable. Multiple actions, procedures, functions, or methods could reference the same resources: "security-category-1.json".

With respect to MCP and WebMCP, inline or referenced JSON or JSON-LD content could contain security-related metadata both: (1) used during secured execution in runtime environments, and (2) presented through MCP APIs' tools descriptions. Both execution-related metadata and API-presentational metadata could be derived from that data in the inline or referenced JSON or JSON-LD resources.

Interestingly, perhaps these inline or referenced and reusable JSON or JSON-LD resources could be composable or compositable.

@metadata("https://example.org/security-resource-use-3.json")
@metadata("https://example.org/security-category-1.json")
function(...)
{

}

Thank you. What do you think of these ideas?


Best regards,
Adam

________________________________

From: Christoph <christoph@christophdorn.com>
Sent: Tuesday, February 24, 2026 2:54 PM
To: public-pm-kr@w3.org <public-pm-kr@w3.org>
Subject: Re: Securing Actions and Procedures

Yes! I am very much interested in this.

I am looking for a way to attach any type of metadata by mapping to a schema. This metadata will be used for all kinds of purposes as a "function" can represent any type of "action" on an "entity" in my system.

Christoph


On Tue, Feb 24, 2026, at 2:48 PM, Adam Sobieski wrote:
PM-KR Community Group,

Hello. In some programming languages (e.g., C#, Java, and JavaScript), developers can use attributes, annotations, or decorators to provide metadata on functions and methods. Approaches for representing procedural knowledge, including programmatic and executable approaches, could, then, include expressiveness for providing metadata on actions and procedures.


In C#, attributes resemble:

[metadata(...)]
public void function(...)
{

}

In Java, annotations resemble:

@metadata(...)
public void function(...)
{

}

In JavaScript, decorators resemble:

@metadata(...)
function(...)
{

}


Metadata could be used to declare preconditions and effects for actions and procedures (see also: STRIPS, ADL, PDDL). Extensible metadata could also simplify a number of important scenarios such as: computer security, access-control, and user- and agentic-permission-related topics.

As interesting, here are some initial hyperlinks about these topics:


.NET

https://en.wikipedia.org/wiki/Code_Access_Security


Java

https://apereo.github.io/cas/7.3.x/planning/Architecture.html


MCP

https://modelcontextprotocol.io/specification/2025-06-18/server/tools

https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1483

https://modelcontextprotocol-security.io/build/tool-metadata-spec/


WebMCP

https://github.com/webmachinelearning/webmcp/issues/44

https://github.com/webmachinelearning/webmcp/issues/45


BPMN

https://ceur-ws.org/Vol-2218/paper17.pdf

https://www.researchgate.net/publication/31367121_A_BPMN_Extension_for_the_Modeling_of_Security_Requirements_in_Business_Processes


Is there any interest, in this group, in considering and discussing comparative approaches (the above and any others) for providing expressiveness to simplify securing actions and procedures?

Are there any other hyperlinks to recommend and share on these topics?


Best regards,
Adam Sobieski