WG 2023 Charter - Security Work Items

[mmccool]

Add security work items to charter.

• onboarding
• security scheme ontology
• signing

These are work items, not deliverables. However, each item indicates which deliverables it would impact.

Note that signing was moved from discovery to here.

[egekorkan]

Regarding Security Scheme Ontology, I would propose to evaluate this as another category of binding template or to integrate security schemes to their corresponding protocol binding template. From my experience so far, there are no security mechanism that is easily applicable to multiple protocols so it would make more sense to include all the ontology in the respective protocol.

[mmccool]

To @EGE: that is a reasonable point, although it might lead to some redundancy. Is it better to have multiple ontologies for a basic password scheme, one per protocol, or one generic scheme that applies to multiple protocols? There is also the potential for multiple protocols to be used in a single TD. With a generic security scheme, we can declare it once and have it apply to each protocol as appropriate. Another way to do it would be to define generic schemes that have appropriate information, and then the protocol binding defines which generic security schemes are applicable to that protocol and how the information provided is to be interpreted. Occasionally a protocol may use a special security scheme that does not map to any of the generic schemes, in which case we would have to define a security scheme just for that protocol, but ideally that would be the exception.

[egekorkan]

I have some ideas cooking up but my vision is to have some generic schemes defined in the TD specification (not even saying basic auth, something more abstract) that are then expanded in the protocol binding. It would be similar to mapping of readproperty to HTTP GET.

We should not have redundancy and that was not my intention.

[mmccool]

I think it's clear though that we do want to take many of the "baked-in" security schemes out of the TD spec, and support them with vocabulary extensions, especially when they are protocol-specific. A second-order point is where we put them: into a new document (which could be a registry) or included in another document (like the protocol bindings). Your suggestion to put them into protocol bindings makes sense if they are, in fact, protocol-specific. There ARE some security schemes that apply to multiple protocols, for example api key (when, for example, a key gets embedded in the body of a message) but maybe we can just consider those "structural" and leave them in the TD spec, alongside nosec and combo (and probably auto, which I forgot to mention).

[danielpeintner]

is "JSON-LD documents" the right term.. I would rather say "TD documents" since TD can be JSON or JSON-LD

[sebastiankb]

from today's charter session, the group decided to merge this PR. However, there will be another iteration provided by @mmccool .

There should be also a statement that the approaches should also work without RDF tooling.