Currently there are two assertions in section 6.3 Security which say:
Security schemes MUST be applied using the top level security member of a Thing.
Security schemes MUST NOT be applied to individual Forms.
I understand why this is desirable in order to reduce implementation complexity of Consumers, but I'm concerned about potential implications of that constraint.
Implementation experience with WebThings has shown me that sometimes different authentication schemes need to be used for different protocols or sub-protocols. For example, an implementation of the Basic HTTP Profile may use the OAuth2 or Bearer security scheme with a JSON Web Token in an Authorization header (in: "header"), but an implementation of the HTTP SSE Profile may have to include that token in a query string (in: "query"), because web browsers do not support Authorization headers with EventSource. That is also the case for WebSockets.
In order to use multiple protocol bindings or multiple profiles in the same Thing Description (e.g. the HTTP Basic Profile and HTTP SSE Profile, or an HTTP protocol binding and WebSocket protocol binding), it may be necessary to provide multiple securityDefinitions, and declare on a form by form basis which security definition should be used for a given protocol binding.
If I understand correctly, if the security member of Thing has multiple values in an array it means that all of those security schemes have to be satisfied in order to access resources. But what is needed in this case is different security definitions for different protocols or sub-protocols.
If these assertions remain, it may make it impossible to implement Things with certain combinations of profiles or protocol bindings.
Currently there are two assertions in section 6.3 Security which say:
I understand why this is desirable in order to reduce implementation complexity of Consumers, but I'm concerned about potential implications of that constraint.
Implementation experience with WebThings has shown me that sometimes different authentication schemes need to be used for different protocols or sub-protocols. For example, an implementation of the Basic HTTP Profile may use the OAuth2 or Bearer security scheme with a JSON Web Token in an
Authorizationheader (in: "header"), but an implementation of the HTTP SSE Profile may have to include that token in a query string (in: "query"), because web browsers do not support Authorization headers with EventSource. That is also the case for WebSockets.In order to use multiple protocol bindings or multiple profiles in the same Thing Description (e.g. the HTTP Basic Profile and HTTP SSE Profile, or an HTTP protocol binding and WebSocket protocol binding), it may be necessary to provide multiple
securityDefinitions, and declare on a form by form basis which security definition should be used for a given protocol binding.If I understand correctly, if the
securitymember of Thing has multiple values in an array it means that all of those security schemes have to be satisfied in order to access resources. But what is needed in this case is different security definitions for different protocols or sub-protocols.If these assertions remain, it may make it impossible to implement Things with certain combinations of profiles or protocol bindings.
I suggest removing these assertions.