WIP: Allow auto security scheme for other permitted security schemes

[mmccool]

WIP: Needs some cleanup and rebasing to be relevant.

Resolves https://github.com/w3c/wot-profile/issues/313

1. Rather than simply adding "auto" to the list of supported schemes, which would have opened up negotiation of schemes NOT on the permitted list, I added an additional assertion that allows "auto" (and therefore security negotiation) but says only configurations consistent with the other permitted schemes is allowed
2. I'm not sure what the intent of assertion common-constraints-security-6 is.
   • If it is for Discovery, then it overlaps with common-constraints-security-7 and is redundant.
   • If is not, and the intent is to allow security bootstrapping for other affordances, then "auto" should be used in the TD to indicate this.
   • Either way, I think it should be removed, or perhaps changed to the following:

   • 
       Conformant Consumers MUST support the <a href="https://w3c.github.io/wot-thing-description/#autosecurityscheme"><code>AutoSecurityScheme</code></a>  
       and security negotiation for all <a href="#common-constraints-security-1">other permitted security schemes</a>.
     </span></p>```

3. Should we restrict security bootstrapping for Discovery to the same set of permitted security schemes, i.e. restrict common-security-constraints-7 similarly? In particular the cited section in Discovery permits Bearer and Digest, which are not currently in the list for Profiles. It would be weird to permit these additional security schemes for Discovery but not for other accesses (and it also increases the requirements on Consumers). If a Thing follows a profile it would be "promising" not to offer such a scheme during negotiation, so there is no reason for a Consumer/Discoverer to support it if it is trying to discover Things matching its profile. However... the whole point of negotiation is that both Consumer and Thing will be collaborating on picking a scheme they both support.

I will hold this PR in "draft" state until we resolve points 2 and 3.

---

Preview | Diff

[benfrancis]

I'm not sure what the intent of assertion common-constraints-security-6 is.

• If it is for Discovery, then it overlaps with common-constraints-security-7 and is redundant.

• common-constraints-security-6 is a requirement for Consumers
• common-constraints-security-7 is a requirement for Things

• Either way, I think it should be removed, or perhaps changed to the following:

• Conformant Consumers MUST support the <a href="https://w3c.github.io/wot-thing-description/#autosecurityscheme"><code>AutoSecurityScheme</code></a>  
  and security negotiation for all <a href="#common-constraints-security-1">other permitted security schemes</a>.
  </span></p>```

I don't think so, "security negotiation" for interaction affordances (as per the auto security scheme used by Forms) is a different mechanism to "security bootstrapping" to gain access to a Thing Description.

3. Should we restrict security bootstrapping for Discovery to the same set of permitted security schemes, i.e. restrict common-security-constraints-7 similarly?

That is the intent of the current assertions:

• "Conformant Consumers MUST support all of these security schemes."
• "Conformant Consumers MUST support security bootstrapping for all implemented security schemes"

I do acknowledge this is confusing though because it conflates "security schemes" in the general sense (applied to the authentication of a Thing Description) with "security schemes" in the specific sense of SecurityScheme metadata inside a Thing Description.

In general I think we need to more clearly distinguish between the security requirements for accessing a Thing Description vs. the security requirements of Forms. Perhaps separate sub-sections would help:

1. Thing Description Security
2. Form Security

[mmccool]

Going to change this to non-draft. Propose we merge this and discuss and resolve points 2 and 3 in new issues/PRs.

[mlagally]

Arch call on Dec 7th: Members on the call support to merge this unless we get an objection within a week, i.e. until Dec 14th. McCool will create new issues for points 2 and 3 to continue the discussions separately.

[egekorkan]

@mlagally do you mean a formal objection? I do not think that W3C formal objection applies to individual PRs related to specwork.

If only my opinion is enough, I do not see the reason to include this. My main reason that any feature you are putting in a normative W3C technical report needs 2 implementations. Given that we are struggling to find implementations, I think it is a bad idea to increase the implementation requirements and thus the effort. The issue linked to this PR has literally no information on why this is needed.

[benfrancis]

What actually needs to be implemented to support "automatic negotiation" for the BasicSecurityScheme and OAuth2SecurityScheme?

Section 5.3.3.3 of the TD spec only provides a reference for Basic Authentication, and I'm not even sure it's linking to the right RFC.

[mmccool]

Regarding Ben's question about implementation, negotiation is how HTTP normally works, so implementation is trivial (in fact required if you are implementing HTTP according to its spec). What "auto" really means is that no information is provided in advance in the TD, it has to be discovered dynamically using normal HTTP mechanisms. This is also to address a security consideration - there are some cases when you don't want to advertise the security mechanism used in advance (e.g. to discourage people scanning for vulnerabilities).

However, I would like to restrict HTTP negotiation to only the "permitted" subset. If we just add auto to the "permitted" list it opens it up to ANYTHING supported by HTTP.

[benfrancis]

@mmccool wrote:

Regarding Ben's question about implementation, negotiation is how HTTP normally works, so implementation is trivial (in fact required if you are implementing HTTP according to its spec).

OK, so if I understand correctly the Consumer would need to support 401,302, and 303 responses* to all HTTP requests and automatically determine from the response whether to use the Basic or OAuth2 security scheme. That seems reasonable since we essentially already require Consumers support the same approach for "bootstrapping" access a Thing Description.

Out of interest though, how does automatic security negotiation work for the client flow of OAuth2?

According to section 7.1.2 of the WoT Discovery specification:

Note that the other OAuth2 flows supported in WoT Thing Description 1.1, client and device, both expect the initial access to be to the authentication server, not the final endpoint, and so cannot be used via security bootstrapping.

In an out-of-the-box discovery type scenario, how would a Consumer find the URL of an authentication server if it isn't provided in the Thing Description?

This is also to address a security consideration - there are some cases when you don't want to advertise the security mechanism used in advance (e.g. to discourage people scanning for vulnerabilities).

Side note: this sounds like security by obscurity, which I would generally not recommend.

* Technically HTTP Basic authentication can also use the 407 Proxy Authentication Required response code, but that's not currently on the list of recommended responses in WoT Profile.