SecuritySchemas and Links

[relu91]

As raised in the Discovery call today, in the current TD specification is not clear if the securitySchemas are also applicable to Links. I did a second quick glance at the spec and in SecurityScheme section there is no specific sentence declaring that the set of securitySchemas is related to only forms or links or both of them.

[relu91]

One naive solution would be to extend the introducation text in the same section mentioned above from:

Metadata describing the configuration of a security mechanism. The value assigned to the name scheme MUST be defined within a Vocabulary included in the Thing Description, either in the standard Vocabulary defined in § 5. TD Information Model or in a TD Context Extension.

to something like (if we decide that they are only relevant for forms):

Metadata describing the configuration of a security mechanism. The value assigned to the name scheme MUST be defined within a Vocabulary included in the Thing Description, either in the standard Vocabulary defined in § 5. TD Information Model or in a TD Context Extension. Security Definitions are related only to forms; links SHOULD use a standard HTTP authentication negotiation mechanism if they link to restricted resources.

[egekorkan]

One problem I see with including or not including it, is :

• links inherit security: links need security member if they use a different one than the rest
• links do not inherit security and are nosec: how to specify that the link needs security?

[egekorkan]

In the call of 21.07, we have agreed on:

• Adding the security keyword in the links container.
• By default, links follow a no_sec scheme, even if the Thing does not have that scheme in its securityDefinitions. This needs to be added as an assertion.
• Later on (in TD 2.0), we can have a term in the root level called linksSecurity. This would make it clear that securityDefinitions does not apply to links.

[mmccool]

Overlooked this since it was missing the security labels; added. I can go ahead and implement this (although, having "nosec" as the default scheme is inconsistent with our policy elsewhere, I don't see any way around it while maintaining compatibility)

[mmccool]

So unfortunately we did not get around to implementing this. Should we try to squeeze it in before CR, or defer to TD 2.0?

[mmccool]

BTW I think the assumption is that links would follow "auto", e.g. the "normal" mechanisms to negotiate access would be followed. The assumption is not that they don't have security, it's just the TD does not describe what they need.

[egekorkan]

Actually, can one simply not use a term from our ontology by prefixing it? This way, we can put it as an example