docs: State security considerations for ID tokens and security tokens

SUMMARY.md

@@ -5,6 +5,7 @@
 * [Dataspace Protocol v0.8](./README.md)
 * [Terminology](./model/terminology.md)
 * [Information Model](./model/model.md)
+* [Security](./model/security.md)
 
 ## Catalog
 

catalog/catalog.binding.https.md

@@ -78,8 +78,8 @@ described by the [Catalog Protocol Specification](catalog.protocol.md).
 
 ### 3.1 Authorization
 
-A catalog service may require authorization. If the catalog service requires authorization, requests must include an HTTP `Authorization` header with a token. The contents of  
-the token are undefined by may be an OAUTH2, Web DID, or other access token type.
+A catalog service may require authorization. If the catalog service requires authorization, requests must include an HTTP `Authorization` header with a token.
+In that case, security considerations mentioned in section [Security](../model/security.md) apply further.
 
 ### 3.2 Versioning
 

catalog/catalog.protocol.md

@@ -168,8 +168,12 @@ The discovery protocol adopted by a particular dataspace defines how a consumer
 
 It is expected (although not required) that catalog services implement access control. A catalog as well as individual catalog _datasets_ may be restricted to trusted parties.
 The catalog service may require consumers to include a security token along with a `CatalogRequestMessage.` The specifics of how this is done can be found in the relevant
-catalog binding specification. In addition, this specification does not define the contents of the security token. It is expected different security mechanisms may be used such
-as [OAuth2 2.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-06) or [did:web](https://w3c-ccg.github.io/did-method-web/).
+catalog binding specification.
+
+This specification does not define the contents of security tokens, though security considerations mentioned in section [Security](../model/security.md) apply.
+
+It is expected different security mechanisms may be used such as [OAuth2 2.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-06) or 
+[did:web](https://w3c-ccg.github.io/did-method-web/).
 
 ### 4.4 Catalog Brokers
 

model/model.md

@@ -19,9 +19,12 @@ Note that all relationships are multiplicities unless specified.
 - A `Participant Agent` performs tasks such as publishing a catalog or engaging in an asset transfer. In order to accomplish these tasks, a participant agent may
   use a _**verifiable presentation**_ generated from a _**credential**_ obtained from a third-party issuer. A participant agent may also use an _**ID token**_ issued by a
   third-party identity provider. Note that a participant agent is a logical construct and does not necessarily correspond to a single runtime process.
-- An `Identity Provider` is a trust anchor that generates `ID tokens` used to verify the identity of a `Participant Agent`. Multiple identity providers may operate in
-  a dataspace. The identity standard used by a provider is not defined but could be, for example, _OAuth2_ or _Decentralized Identifiers using did:web_. An identity provider may be a third-party
-  or a participant itself (for example, in the case of decentralized identifiers).
+  It is the responsibility of adopters of this standard to consider security threats like session hijacking. Protection can be accomplished by means like binding of
+  `verifiable presentations` to public keys of their holder, used by transport protocol encryption.
+- An `Identity Provider` is a trust anchor that generates `ID tokens` used to verify the identity of a `Participant Agent`. Multiple identity providers may operate in a dataspace.
+  The identity standard used by a provider is not defined but could be, for example, _OAuth2_ or _Decentralized Identifiers using did:web_. An identity provider may 
+  be a third-party or a participant itself (for example, in the case of decentralized identifiers).
+  For security considerations regarding these tokens, see [Security](./security.md).
 - A `Credential Issuer` issues _verifiable credentials_ used by participant agents to allow access to assets and verify usage control.
 
 The diagram below depicts the relationships between `ParticipantAgent` types:

model/security.md

@@ -0,0 +1,19 @@
+# 3 Security
+
+This section outlines generic security recommendations which should be considered when implementing the Dataspace protocol.
+
+# 3.1 Token Security
+
+Dataspaces use tokens for identity verification ("`ID tokens`") and optionally other means like authorization of certain message exchanges.
+The identity standard used in a Dataspace is not defined within this document, but could be, for example, _OAuth2_ or Decentralized Identifiers using _did:web_.
+
+It is the responsibility of adopters of this standard to consider relevant security threats and mitigate them wherever possible.
+
+This subsection provides an incomplete list of attack vectors that should receive special attention.
+
+# 3.1.1 Session Hijacking
+
+Session Hijacking describes an attack where stolen or leaked session credentials, i.e. tokens, are used by possibly malicious actors that were not supposed to use them.
+
+Protection against session hijacking can be accomplished by means like binding of tokens to public keys of their holder, used by transport protocol encryption. In the case of TLS-protected transports like HTTPS, this could be achieved through inclusion of certificate fingerprints, belonging to certificates used by the owner of the token, into the signed token.
+Means like inclusion of the correct receiver(s) into token could also be an option, but may only partially mitigate the issue.

negotiation/contract.negotiation.binding.https.md

@@ -33,8 +33,9 @@ an HTTP code 400 (Bad Request) with an `ContractNegotiationError` in the respons
 
 ### 2.3 Authorization
 
-All requests should use the `Authorizartion` header to include authorization data as specified by an authorization protocol such as [OAuth2](https://www.rfc-editor.org/rfc/rfc6749)
-. The `Authorization` HTTP header is optional if the connector does not require authorization. This specification does not mandate the use of a particular authorization standard.
+All requests should use the `Authorization` header to include authorization data as specified by an authorization protocol such as [OAuth2](https://www.rfc-editor.org/rfc/rfc6749).
+The `Authorization` HTTP header is optional if the connector does not require authorization. This specification does not mandate the use of a particular authorization standard.
+When used, security considerations mentioned in section [Security](../model/security.md) apply.
 
 ### 2.4 The provider `negotiations` resource
 

transfer/transfer.process.binding.https.md

@@ -34,8 +34,9 @@ an HTTP code 400 (Bad Request) with an `TransferError` in the response body.
 
 ### 2.3 Authorization
 
-All requests should use the `Authorizartion` header to include authorization data as specified by an authorization protocol such as [OAuth2](https://www.rfc-editor.org/rfc/rfc6749)
-. The `Authorization` HTTP header is optional if the connector does not require authorization. This specification does not mandate the use of a particular authorization standard.
+All requests should use the `Authorization` header to include authorization data as specified by an authorization protocol such as [OAuth2](https://www.rfc-editor.org/rfc/rfc6749).
+The `Authorization` HTTP header is optional if the connector does not require authorization. This specification does not mandate the use of a particular authorization standard.
+When used, security considerations mentioned in section [Security](../model/security.md) apply.
 
 ### 2.4 The provider `transfers` resource