docs: Fix unclear security properties of "security tokens"

[milux]

This issue is somewhat related to #50, yet more specific.

This specification currently mentions security tokens multiple times, also stating that OAuth or did:web might be good candidates for such tokens. However, it does not mention the utter importance of relay protection or any other security properties of such tokens.

In a typical setup, it is very likely that the same token will be used for transactions with multiple parties. In a naive implementation, any such party may misuse a received token to impersonate the actual owner of the token or request resources on its behalf.
This issue can only be solved by some sort of cryptographic binding as already described in IDS-G, yet there is no mention at all of such semantic requirements, conveying the wrong impression that properly done security can simply be "plugged" into an existing DataSpace by adding tokens, which is just plain wrong in most cases.

In my view, the current specification encourages unsafe implementations with semantic security faults that already have been discussed years ago (and also solved for e.g. HTTPS and IDSCP2 bindings) in the IDS context, see International-Data-Spaces-Association/IDS-G#79

I see two things that are needed here in order to fix this:

1. We should absolutely mention semantic security requirements regarding these tokens, at least on a high level, such that the issue is understood by adopters of this standard.
2. When providing a documented binding example like HTTPS, this binding should cover at least a high level description of how this security property can be achieved, see IDS-G PR above.

The only reasonable alternative in my opinion would be to completely strip any notion of "security tokens" from this standard.
This doesn't solve the issue, and of course I'm all for the former option, but removing the "security tokens" altogether at least makes clear that this standard is not intended to recklessly promote half-baked "security features", promoting this task to another layer.

I will do a PR ASAP to suggest a fix for this issue.

[sebbader-sap]

Marking it with wontfix as I have the impression that either the proposed solutions have already been merged (see the linked PR) or are out of scope for the DSP.

[milux]

I think we opted for the latter option (removing ambiguous notions) a long while ago. So we may consider this as completed.

[ssteinbuss]

not in scope, closing