HTTP security flexibility

[egekorkan]

Currently, the TD allows quite a lot of flexibility for HTTP BasicAuth and API Key (others too but let's start here?). I was talking about this with @danielpeintner on Wednesday and also supervising @ms499 who is doing an analysis of the security in general. This was talked briefly in the TD call yesterday since we need implementations of these features if we want to keep them in the spec.

I will put some initial analysis that should be extended and possibly better organized:

• BasicAuth is currently done only in the header with the default header name. This is the case for Thing (not an issue) but the Consumer side actually does not try to understand the TD to put the hashed username password in the correct place. It is thus not flexible and done with implicit assumptions. At least, if the credentials are needed somewhere else and node-wot does not do it yet, an error should be shown.
• APIKey can be put in the body and in different places in the body. This is the main reason of the whole paragraph of features failing in the TD spec at https://w3c.github.io/wot-thing-description/#sec-body-name-json-pointer . This is somewhat messy since it requires the protocol to interfere with the payload.

I am not sure if this is the best place to discuss this and think of what we should do in the future. This issue can be seen more as a discussion I think.

[relu91]

Note point 2 is important for our dev meeting we should prioritize this issue. I'm also creating a label to find issues related to TD assertions.