WebIDs MUST use a secure protocol

[matthieubosquet]

All resources used in the context of Solid Authentication and Authorization MUST use a secure protocol.

Namely, a WebID used for Authentication MUST use the https protocol. That is true of both client and user WebIDs.

Currently, the specification states: "a WebID is a HTTP URI". I couldn't find any specific requirements about security in transit.

I appreciate that it seems a bit like stating the obvious, but I reckon it is fundamentally important enough to require an extension of section 3, probably with a 3.2 Encryption of WebIDs in transit.

See also: https://www.ncsc.gov.uk/collection/cloud-security/implementing-the-cloud-security-principles/data-in-transit-protection

[csarven]

Implied as per:

• WebID is indeed a HTTP URI in that both "http" and "https" URI schemes can be used.
• HTTP over TLS.
• "https" URI scheme depends on TLS.
• Solid-OIDC depends on TLS (Security Considerations).

I agree, the spec can/should be tightened.

As to whether the spec(s) should mandate that the "https" URI scheme MUST be used for WebID in Solid authentication may be worthwhile to consider and some additional checks. From an editorial perspective - not to imply the absolutely correct way because the inner details of the Solid OIDC protocol may escape me - with the goal to keep components somewhat orthogonal, I suggest considering emphasis and need on the HTTP over TLS requirement as opposed to the "https" URI scheme requirement for WebID. The former leaves room for the "http" URI scheme via HTTP+TLS (if/when/how) without sacrificing on the current practice with WebIDs using "https" URI scheme for the purpose of authentication.

See also: RFC 2817, RFC 2818, and https://www.w3.org/DesignIssues/Security-NotTheS.html

[matthieubosquet]

I wholeheartedly agree.

And thanks for the link! I'd love to see the HTTP protocol secure by default and fail to see the reasons why it shouldn't be. Also, the coexistence of URIs served by different protocols does annoy me too.

I have two questions:

• Do you know if there has been progress in the TLS everywhere stream of work or if it exists in any form or shape?
• As far as how to formulate this requirement to remain as open as possible for the future, there is one thing I am not quite sure about: Is TLS not gonna have a successor at some point?

TLS is as far as I understand a renaming of SSL that should be accurate and future-proof, but I'm not sure whether we need to be more generic in the MUST statement followed by a note on current practice. Something like: "WebIDs MUST be transmitted via a secure protocol that ensures integrity of data in transit. See the Internet Best Current Practice documented in [[BCP195]] for details of what this requirement entails.".

[awhillas]

If the WebID is supposed to be public why does it need to be transmitted in a secure manner? What is it hiding? What does the secure transmission of a public document add?

[acoburn]

Why does it need to be transmitted in a secure manner?

Here, security ensures that the data is not tampered with in transit.

What is it hiding?

This is not about confidentiality, it is about integrity.

What does the secure transmission of a public document add?

As mentioned above, this is about ensuring integrity.

[awhillas]

How do you tamper with the integrity of a HTTP request?

[acoburn]

How do you tamper with the integrity of a HTTP request?

Any MITM attack would allow one to tamper with an HTTP exchange. The specific details depend on the specific target of the attack and the resources available to the attacker.