Clarify how TLS works and when sensitive information in URIs should not be used

[diderikvw]

Remove BSN as example of sensitive information and add note.

[diderikvw]

@TimvdLippe Te overwegen om ook als noot toe te voegen: bij TLS worden het URL-pad en de query strings ook versleuteld, dus elke tussenliggend component kan eventuele gevoelige gegevens hierin niet zien en niet loggen. Met name een relevante kanttekening bij system-to-system-integraties.

[TimvdLippe]

@diderikvw Kun je deze PR updaten met jouw voorstel? Dat kunnen we dat voorleggen aan de TO-leden om te kijken wat ze daarvan denken.

[diderikvw]

@TimvdLippe Ja, heb ik gedaan.

Hoe ik TLS begrijp, klopt dit gedeelte niet:

Even when using TLS connections, information in URIs is not secured. URIs can be cached and logged outside of the servers controlled by clients and servers. Any information contained in them should therefore be considered readable by anyone with access to the network (in the case of the internet, the whole world) and MUST NOT contain any sensitive information.

Daarom heb ik de tekst wat rigoreuzer aangepast.

[TimvdLippe]

Thanks voor de cleanup! vi for the win 😉 Ik heb @mrtn78 toegevoegd als reviewer, want die weet veel van dit domein af. Qua tijdsplanning zullen we dit morgen niet meer op het TO kunnen bespreken, maar laten we streven naar bespreking op het volgende TO.

[TimvdLippe]

Wat kleine tekstuele nits. De HTML heb ik zelf niet getest, maar zou gewoon moeten werken.

[TimvdLippe]

Suggested change

	<p class="note">The term sensitive is deliberatly left undefined in this document.</p>
	<p class="note">The term sensitive is deliberately left undefined in this document.</p>

[TimvdLippe]

Om de zinnen iets beter te laten lopen en korter te maken:

Suggested change

	<p>When using TLS connections, the path and query information in URIs are secured just like the message headers and body. However, before the TLS connection starts on the server, after the TLS connection ends on the client and whenever the TLS protocol is terminated and newly initiatied in between, URIs can be cached and logged, as can headers and bodies. For REST API's that are accessed directly from user devices, like web browsers, do not put client secrets used for authentication, privacy sensitive information or any other information which should not be shared in the URI, since these are directly visible to users, are stored in the web browser's history and cache and can be bookmarked and sent to others.
	<p>When using TLS connections, the path and query information in URIs are secured just like the message headers and body. However, URIs can be cached and logged, as can headers and bodies in the following situations:
	<ul>
	<li>before the TLS connection starts on the server
	<li>after the TLS connection ends on the client
	<li>whenever the TLS protocol is terminated and newly initiated in between
	</ul>
	<p>For REST API's that are accessed directly from user devices, like web browsers, do not put client secrets used for authentication, privacy sensitive information or any other information which should not be shared in the URI. These are directly visible to users, are stored in the web browser's history and cache and can be bookmarked and sent to others.