docs(conn): elaborate on CX conventions on Policies

DEPENDENCIES

@@ -1284,7 +1284,7 @@ npm/npmjs/@types/parse-json/4.0.0, MIT, approved, clearlydefined
 npm/npmjs/@types/parse5/5.0.3, MIT, approved, clearlydefined
 npm/npmjs/@types/parse5/6.0.3, MIT, approved, clearlydefined
 npm/npmjs/@types/prop-types/15.7.5, MIT, approved, clearlydefined
-npm/npmjs/@types/qs/6.9.7, MIT, approved, clearlydefined
+npm/npmjs/@types/qs/6.9.7, MIT, approved, #13991
 npm/npmjs/@types/range-parser/1.2.4, MIT, approved, #10795
 npm/npmjs/@types/react-is/17.0.3, MIT, approved, #8424
 npm/npmjs/@types/react-redux/7.1.25, MIT, approved, #10970

docs-kits/kits/Connector Kit/Adoption View/adoption-view.md

@@ -203,7 +203,7 @@ This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses
 - SPDX-FileCopyrightText: 2023 msg systems AG
 - SPDX-FileCopyrightText: 2023 Mercedes-Benz Group AG
 - SPDX-FileCopyrightText: 2023 Contributors of the Eclipse Foundation
-- Source URL: [https://github.com/eclipse-tractusx/tractusx-edc](https://github.com/eclipse-tractusx/tractusx-edc)
+- Source URL: [https://github.com/eclipse-tractusx/eclipse-tractusx.github.io](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io)
 
 [edc-url]: https://github.com/eclipse-edc/Connector
 

docs-kits/kits/Connector Kit/Adoption View/policies-in-catena.md

@@ -0,0 +1,253 @@
+---
+sidebar_position: 3
+description: 'Conventions and behavior specific to Catena-X'
+title: Policies in Catena-X
+id: connector_kit_adoption_view_policies_cx
+---
+
+## Data Sovereignty in Catena-X
+
+This page extends on the previous section's fundamentals and introduces conventions specific to the Catena-X Dataspace.
+It assumes basic knowledge on `Policies` and their processing. Please go back to [the fundamentals](working-with-policies.md)
+if that's unfamiliar.
+
+Catena-X recommends to focus on `permission` property to further specify the contracts' details. In general,
+every data provider can decide on his or her own under which conditions their data datasets (assets) are shared in the
+network. In practice, this works as long as both parties, Provider and Consumer, have the same understanding of its
+legal meaning. Therefore, standardized such `Constraint`s with their `leftOperand`s and `rightOperand`s are key for
+automation. Still, individual freedom of contract is a very high good and is still possible.
+
+This guidance is however also relevant for Enablement Service Providers building components enabling connectivity to the
+Dataspace (as specified in CX-0018). The authoritative resource for schemas is
+the [Catena-X ODRL Profile](https://github.com/catenax-eV/cx-odrl-profile). It is also available via the [Policy Hub](https://github.com/eclipse-tractusx/policy-hub/blob/main/docs/technical-documentation/requests/example-requests.md)
+that is operated centrally. The API is documented in this Repository and can be accessed with an access token to the
+Portal. It's a convenience feature for the negotiating parties to check if a given offer matches the policy constraints
+agreed by the Catena-X association - for instance by keeping a definite list of valid `rightOperands` to a particular
+`leftOperand` in a `Constraint`.
+
+As mentioned in the primer on policies, Providers and Consumers must have a common
+understanding of the meaning and consequences of `odrl:Offers` and, on a more granular level, their `odrl:Constraints`.
+That's why there is a set of predefined `odrl:Constraints` - all of which have to
+be [accepted explicitly](working-with-policies.md#consumer-side-odrloffer-in-a-contractrequestmessage) and
+some [checked against a Consumer's VP](working-with-policies.md#provider-side-checking-a-consumers-verifiable-presentation)
+additionally. They are formalized in the [Catena-X ODRL profile](https://github.com/catenax-eV/cx-odrl-profile)
+which extends the regular [ODRL vocabulary](https://www.w3.org/TR/odrl-vocab/). Since usage or contract policies are
+highly dependent on the use case,
+they are described by them in their associated KITs and only general elements are explained in the following.
+
+Here's a non-normative overview of these extensions:
+
+### Use Case Framework Constraints
+
+Use Case Framework Constraints are references to legally binding documents set up by the Catena-X association. They
+govern the _"who, with whom, what, where from and where to, why, how, and when"_ of Data Sharing in Catena-X Use-Cases
+([Source](https://catena-x.net/en/catena-x-introduce-implement/governance-framework-for-data-space-operations)).
+Use Case Frameworks are roughly structured along the lines of business scenarios under which a set of business partners
+want to exchange data.
+
+Each Participant commits to a set of Use Case Frameworks during Onboarding. They are granted a set of VCs as proof of
+that commitment. Consequently, Use Case Framework Constraints belong to the kind of `odrl:Constraint`s that have to be
+[checked against a VP](working-with-policies.md#provider-side-checking-a-consumers-verifiable-presentation). The
+complete set is listed in the most current version of standard
+[CX-0050 Framework Credential](https://catena-x.net/fileadmin/user_upload/Standard-Bibliothek/Update_September23/CX-0050-FrameworkAgreementCredential-v.1.0.0.pdf) (
+link opens pdf).
+Use Case Frameworks are referred to in a machine-readable way in a Provider's Offers. When a Consumer starts the
+negotiation for said offer, not only will the Policy in the `ContractRequestMessage` be checked but also his
+Credentials. Here's an example of an `odrl:Constraint` referencing a Use Case Framework and invoking the VC-check:
+
+```json
+{
+  "@context": {
+    "odrl": "http://www.w3.org/ns/odrl/2/"
+  },
+  "odrl:leftOperand": "https://w3id.org/catenax/policy/FrameworkAgreement",
+  "odrl:operator": {
+    "@id": "odrl:eq"
+  },
+  "odrl:rightOperand": "traceability:1.0"
+}
+```
+
+### Usage Purposes
+
+Purposes are usually part of a Use Case Framework and restrict the purpose the Consumer is privileged to use the
+obtained data for. Unlike a Use Case Framework Constraint, the purposes are NOT checked against VCs, thus necessary
+for a successful negotiation mechanism is
+only [the Consumer's consent to the Offer](working-with-policies.md#consumer-side-odrloffer-in-a-contractrequestmessage).
+Versions for UsagePurpose `rightOperand`s are typically 1-digit. The complete list of usage purposes in Catena-X is
+publicly available in the [CX ODRL Profile](https://github.com/catenax-eV/cx-odrl-profile). The corresponding documents
+are linked on
+the [Catena-X e.V. homepage](https://catena-x.net/en/catena-x-introduce-implement/governance-framework-for-data-space-operations).
+Here's an example from the Use Case Framework Traceability:
+
+| Predefined Policy                | Typically used where? | Predefined Purpose                                                                                                                                        |
+|----------------------------------|-----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `cx.core.qualityNotifications:1` | Notification API      | The data can be used for quality analysis to identify and select affected components and to send quality notifications to affected customers or suppliers |
+
+A `odrl:Constraint` referencing this purpose looks like this:
+
+```json
+{
+  "@context": {
+    "odrl": "http://www.w3.org/ns/odrl/2/"
+  },
+  "odrl:leftOperand": "https://w3id.org/catenax/policy/UsagePurpose",
+  "odrl:operator": {
+    "@id": "odrl:eq"
+  },
+  "odrl:rightOperand": "cx.core.qualityNotifications:1"
+}
+```
+
+### Contract References
+
+Contract References by default aren't checked against credentials either. They are a vehicle to refer to contracts that
+are not governed by the Catena-X association - for instance bilaterally. Referencing such a contract's identifier can
+be achieved via an `odrl:Constraint` like this:
+
+```json
+{
+  "@context": {
+    "odrl": "http://www.w3.org/ns/odrl/2/"
+  },
+  "odrl:leftOperand": "https://w3id.org/catenax/policy/ContractReference",
+  "odrl:operator": {
+    "@id": "odrl:eq"
+  },
+  "odrl:rightOperand": "contract-123456789"
+}
+```
+
+### Chaining Constraints
+
+If a Policy is supposed to hold multiple constraints, Data Providers may chain them via a logical AND. This can be
+achieved via an `odrl:and` object encapsulating multiple other `odrl:Constraint`s or entering a list of them
+into the `odrl:constraint` property. The example below contains both versions.
+
+Constraints that are supposed to be checked with a logical OR should be published as separate Data Offers.
+
+## Example
+
+This specific Catalog contains one single `dcat:Dataset`, called "json-1-paper". It is the only entry in the top-level
+`dcat:dataset` property. To access this Dataset, the Consumer can choose between two Offers (see the `odrl:hasPolicy`
+property):
+
+- `"Y29udHJhY3QtYmlsYXRlcmFsLXBhcGVyLWV4YW1wbGUtMg==:anNvbi0xLXBhcGVy:ZDA4ZDM5OTgtOGY5ZS00MzBmLThjZDEtZmYwOWQxMmQxYzk5"`
+- `"Y29udHJhY3QtYmlsYXRlcmFsLXBhcGVyLWV4YW1wbGUtMQ==:anNvbi0xLXBhcGVy:ODFkMDI2MWYtNDNlNi00ZTIxLWJkMWYtZmFmZTI3MWQwYzhj"`
+
+```json
+{
+  "@context": {
+    "@vocab": "https://w3id.org/edc/v0.0.1/ns/",
+    "edc": "https://w3id.org/edc/v0.0.1/ns/",
+    "tx": "https://w3id.org/tractusx/v0.0.1/ns/",
+    "dcat": "http://www.w3.org/ns/dcat#",
+    "dct": "https://purl.org/dc/terms/",
+    "odrl": "http://www.w3.org/ns/odrl/2/",
+    "dspace": "https://w3id.org/dspace/v0.8/"
+  },
+  "@id": "693e9b66-04f2-4bfb-b3cd-daf5857b47c9",
+  "@type": "dcat:Catalog",
+  "dcat:dataset": [
+    {
+      "@id": "json-1-paper",
+      "@type": "dcat:Dataset",
+      "odrl:hasPolicy": [
+        {
+          "@id": "Y29udHJhY3QtYmlsYXRlcmFsLXBhcGVyLWV4YW1wbGUtMg==:anNvbi0xLXBhcGVy:ZDA4ZDM5OTgtOGY5ZS00MzBmLThjZDEtZmYwOWQxMmQxYzk5",
+          "@type": "odrl:Set",
+          "odrl:permission": {
+            "odrl:action": {
+              "@id": "http://www.w3.org/ns/odrl/2/use"
+            },
+            "odrl:constraint": {
+              "odrl:and": [
+                {
+                  "odrl:leftOperand": "https://w3id.org/catenax/policy/FrameworkAgreement",
+                  "odrl:operator": {
+                    "@id": "odrl:eq"
+                  },
+                  "odrl:rightOperand": "traceability:1.0"
+                },
+                {
+                  "odrl:leftOperand": "https://w3id.org/catenax/policy/UsagePurpose",
+                  "odrl:operator": {
+                    "@id": "odrl:eq"
+                  },
+                  "odrl:rightOperand": "cx.core.industrycore:1"
+                }
+              ]
+            }
+          },
+          "odrl:prohibition": [],
+          "odrl:obligation": []
+        },
+        {
+          "@id": "Y29udHJhY3QtYmlsYXRlcmFsLXBhcGVyLWV4YW1wbGUtMQ==:anNvbi0xLXBhcGVy:ODFkMDI2MWYtNDNlNi00ZTIxLWJkMWYtZmFmZTI3MWQwYzhj",
+          "@type": "odrl:Set",
+          "odrl:permission": {
+            "odrl:action": {
+              "@id": "http://www.w3.org/ns/odrl/2/use"
+            },
+            "odrl:constraint": [
+              {
+                "odrl:leftOperand": "https://w3id.org/catenax/policy/FrameworkAgreement",
+                "odrl:operator": {
+                  "@id": "odrl:eq"
+                },
+                "odrl:rightOperand": "traceability:1.0"
+              },
+              {
+                "odrl:leftOperand": "https://w3id.org/catenax/policy/ContractReference",
+                "odrl:operator": {
+                  "@id": "odrl:eq"
+                },
+                "odrl:rightOperand": "contract-123456789"
+              },
+              {
+                "odrl:leftOperand": "https://w3id.org/catenax/policy/UsagePurpose",
+                "odrl:operator": {
+                  "@id": "odrl:eq"
+                },
+                "odrl:rightOperand": "cx.core.industrycore:1"
+              }
+            ]
+          },
+          "odrl:prohibition": [],
+          "odrl:obligation": []
+        }
+      ],
+      "dcat:distribution": [
+        {
+          "@type": "dcat:Distribution",
+          "dct:format": {
+            "@id": "HttpData-PULL"
+          },
+          "dcat:accessService": "911f5da0-c9ee-4259-9a95-39428d08f767"
+        }
+      ],
+      "version": 1.0,
+      "content-type": "application/json",
+      "name": "json-1-paper",
+      "description": "Asset json-1-paper for test purposes",
+      "id": "json-1-paper"
+    }
+  ],
+  "dcat:service": {
+    "@id": "911f5da0-c9ee-4259-9a95-39428d08f767",
+    "@type": "dcat:DataService",
+    "dct:terms": "connector",
+    "dct:endpointUrl": "https://provider-dsp-end.point/api/v1/dsp"
+  },
+  "participantId": "PROVIDER-BPNL"
+}
+```
+
+## Notice
+
+This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).
+
+- SPDX-License-Identifier: CC-BY-4.0
+- SPDX-FileCopyrightText: 2023 Contributors of the Eclipse Foundation
+- Source
+  URL: [https://github.com/eclipse-tractusx/eclipse-tractusx.github.io](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io)

docs-kits/kits/Connector Kit/Adoption View/working-with-policies.md

@@ -0,0 +1,126 @@
+---
+sidebar_position: 2
+description: 'General Information on EDC Policies'
+title: Working with Policies
+id: connector_kit_adoption_view_policies
+---
+
+## Working with Policies
+
+This section includes some general remarks on the concept of `Policies` and how they are treated in the EDC. The entire
+page is independent of the conventions in the Catena-X Dataspace. For that, please check [Policies in Catena-X](policies-in-catena.md).
+
+Policies are a formalization of the terms under which a Provider extends an offer to the Dataspace. The [Dataspace
+Protocol Specification](https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol)
+has selected the [Open Digital Rights Language (ODRL)](https://www.w3.org/TR/odrl-model/) as a formalism and vocabulary to describe such offers.
+This site (and its [specialization for Catena-X](policies-in-catena.md)) exclusively cover the topic of Policies in the
+sense of the Dataspace Protocol. The EDC also uses ODRL-Policies to restrict visibility on Catalog-Entries - calling
+them [Access Policies](https://github.com/eclipse-tractusx/tractusx-edc/blob/main/docs/usage/management-api-walkthrough/02_policies.md#access--usage-policies). Selecting the right Access Policies is a matter of the individual Data Provider and not
+regulated by the Dataspace. Doing it properly however is essential to comply with fundamental anti-trust and information
+security requirements.
+
+Like all payloads that get passed between connectors, ODRL is an RDF-based description language that is on the wire
+serialized as JSON-LD. JSON-LD is namespace-aware JSON with a couple of twists that one should be aware of when working
+with it (like "Structures may be semantically equivalent even though, schematically, they are clearly not"). ODRL
+enables a Provider to be very specific when it comes to the usage of data: What may a consumer do with it? What
+obligations does a consumer incur when accepting the offer?
+
+The first time the Consumer encounters a Policy is when evaluating a Provider's [Catalog](https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol/catalog/catalog.protocol). It contains Offers
+of `@type` `odrl:Set` which is a [subclass](https://www.w3.org/TR/odrl-model/#policy-set) of `odrl:Policy`.
+All terms can be used interchangeably, Offer is most common. Their content is contained in the
+`odrl:permission`, `odrl:prohibition` and `odrl:obligation` properties. They hold `odrl:Rules` that have to be
+satisfied by the Consumer. There's two ways that can happen.
+
+### Consumer-side: `odrl:Offer` in a `ContractRequestMessage`
+
+Firstly, when transmitting a [`ContractRequestMessage`](https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol/contract-negotiation/contract.negotiation.protocol#id-2.1-contract-request-message)
+(for example triggered via the EDC's [contract-negotiations API](https://github.com/eclipse-tractusx/tractusx-edc/blob/main/docs/usage/management-api-walkthrough/05_contractnegotiations.md)), the
+Consumer must signify consent to the Offer by including it in the Request and adding the `odrl:target` property on the
+level of an `odrl:Offer`. It is a very, very bad idea to simply copy the next-best Offer from the Catalog and replay it
+to the Provider. Instead, Consumers must perform internal checks which (if any) Offer proposes terms that they want to
+agree to. It is possible (though not usual) to encode obligations in the in an `odrl:Offer` that a Consumer must
+satisfy. Returning a `ContractRequestMessage` to the Provider, echoing the pricing information, would represent a
+legally binding agreement in accordance to the conditions proposed by the Provider's Offer. Thus, selecting an offer
+extended by a Provider company should thus be handled with appropriate care.
+
+The Provider will usually accept the ContractRequest only if the extended Offer is semantically equivalent to his own
+as distributed via the Catalog.
+
+### Provider-side: Checking a Consumer's Verifiable Presentation
+
+In addition to checking the Offer's structure (as above), Providers' Connectors have the chance to query the Consumer's
+Verifiable Presentation (VP). A VP is a set of Verifiable Credentials (VCs) that a Consumer may have been issued by a
+trusted third party. In this VC, a Provider may find additional information if a Consumer is eligible to pass a certain
+`odrl:Constraint`. Transfer of VPs is handled automatically between the Participants' Identity Wallets by means of the
+[IATP VPP](https://github.com/eclipse-tractusx/identity-trust/blob/main/specifications/verifiable.presentation.protocol.md).
+
+If, for example, the Consumer tries to negotiate for an Offer that is extended only to interested
+parties from civil society (like an NGO), simply pretending to be an NGO shouldn't be enough. It has to be verified and
+can be verified with help of the VP. For that, a "NonGovernmentalOrganizationCredential" could be issued during the
+onboarding process according to the role a Participant assumes in the Dataspace. For more on the interrelation between
+Credentials and Constraints, refer to standards CX-0018 and CX-0149.
+
+A offer containing a `odrl:Use` permission with a `odrl:Constraint` could (in a hypothetical scenario) look like this:
+
+```json
+{
+  "@context": {
+    "odrl": "http://www.w3.org/ns/odrl/2/"
+  },
+  "@id": "Y29udHJhY3QtYmlsYXRlcmFsLXBhcGVyLWV4YW1wbGUtNA==:anNvbi0xLXBhcGVy:Y2JhMGFmM2QtZTIwYi00ZjExLThlZmQtM2FhMzcyZmI1Nzhh",
+  "@type": "odrl:Set",
+  "odrl:permission": {
+    "odrl:action": {
+      "odrl:type": {
+        "@id": "http://www.w3.org/ns/odrl/2/use"
+      }
+    },
+    "odrl:constraint": {
+      "odrl:and": [
+        {
+          "odrl:leftOperand": "https://w3id.org/some-dataspace/role",
+          "odrl:operator": {
+            "@id": "odrl:eq"
+          },
+          "odrl:rightOperand": "NGO"
+        }
+      ]
+    }
+  },
+  "odrl:prohibition": [],
+  "odrl:obligation": []
+}
+```
+
+The Constraint would in that case be checked against the `"type"` property, attesting the information that the presented
+VC does in fact attest that the holder is a Non-Governmental Organization. A Provider Connector would have to have
+appropriate logic implemented to extract relevant information from the VP to satisfy the `odrl:Constraint`.
+
+```json
+{
+  "@context": [
+    "https://www.w3.org/2018/credentials/v1",
+    "https://w3id.org/mydataspace/credentials/v1.0.0"
+  ],
+  "id": "1f36af58-0fc0-4b24-9b1c-e37d59668089",
+  "type": [
+    "VerifiableCredential",
+    "NonGovernmentalOrganizationCredential"
+  ],
+  "issuer": "did:web:com.example.issuer",
+  "issuanceDate": "2021-06-16T18:56:59Z",
+  "expirationDate": "2022-06-16T18:56:59Z",
+  "credentialSubject": {
+    "id": "did:web:com.example.participant",
+    "holderIdentifier": "BPNL000000001"
+  }
+}
+```
+
+## Notice
+
+This work is licensed under the [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode).
+
+- SPDX-License-Identifier: CC-BY-4.0
+- SPDX-FileCopyrightText: 2023 Contributors of the Eclipse Foundation
+- Source URL: [https://github.com/eclipse-tractusx/eclipse-tractusx.github.io](https://github.com/eclipse-tractusx/eclipse-tractusx.github.io)