diff --git a/docs/developer/decision-records/2025-05-28-dataspace-profile-context/README.md b/docs/developer/decision-records/2025-05-28-dataspace-profile-context/README.md
new file mode 100644
index 0000000000..af474a3189
--- /dev/null
+++ b/docs/developer/decision-records/2025-05-28-dataspace-profile-context/README.md
@@ -0,0 +1,41 @@
+# Dataspace Profile Context
+
+## Decision
+
+We'll introduce the concept of "Dataspace profile context", which will enable a connector runtime to serve requests for multiple
+dataspaces with potentially different protocol versions, authentication, vocabulary and policies. 
+
+## Rationale
+
+At the moment the EDC connector only supports multiple protocol versions at the same time, by having pluggable
+modules.
+
+The Dataspace Profile Ccontext is an higher-level concept that defines a set of:
+- wire protocol, version and binding
+- authentication protocol
+- policy functions
+- vocabulary (jsonld context)
+- scopes
+- identifier resolution
+
+## Approach
+
+A `DataspaceProfileContextRegistry` service will be in place, on which a `DataspaceProfileContext` can be registered.
+
+By default, there will be an hardcoded context that uses a particular combination of DSP, DSP, vocabulary and so on; such
+version will be useful for testing and samples, but for a production use the adopters must explicitly define and register
+the expected dataspace contexts by extension.
+
+So, for example, if a connector is supposed to support multiple DSP version, there will be the need to explicitly register
+one profile for every version, same will happen with multiple DCP version and so on.
+
+Every profile will be represented by a different protocol endpoint, and it will be advertised in the `.well-known/dspace.version`
+endpoint.
+
+### Additional Notes
+To be backward compatible, the `profile` information will be passed to management-api and stored as `protocol`, so out of
+the box the default profile name will be the DSP version. In the future this could be adapted and the `protocol` attribute/field
+could be renamed to `profile`, but there's no urgency to do that.
+
+To permit certain assets to be published only on certain profiles the `assetsSelector` field of the `ContractDefinition`
+can be used, no plans to have a strict correlation between Assets and Dataspace Profile Contexts at the moment.
diff --git a/docs/developer/decision-records/README.md b/docs/developer/decision-records/README.md
index e55dec308f..8dba09a72e 100644
--- a/docs/developer/decision-records/README.md
+++ b/docs/developer/decision-records/README.md
@@ -79,3 +79,4 @@
 - [2025-03-14 Prioritized Transfer Services](./2025-03-14-prioritized-transfer-services)
 - [2025-04-15 Contract Agreement policy scope](./2025-04-25-agreement-policy-scope)
 - [2025-04-30 Finalize phase](./2025-04-30-finalize-phase)
+- [2024-06-11 Dataspace Profile Context](2025-05-28-dataspace-profile-context)