international-data-spaces-association/ids-specification

The Dataspace Protocol is a set of specifications designed to facilitate interoperable data sharing between entities governed by usage control and based on Web technologies. These specifications define the schemas and protocols required for entities to publish data, negotiate Agreements, and access data in a data space

ids-specification's Issues

Add details for TransferCompletionMessage

Provide more content in transfer.process.protocol.md.

Differences between `TransferTerminationMessage` and `TransferError`

Reading through the Transfer Process protocol file it's not really clear when a TransferTerminationMessage should be preferred to a TransferError.

Seems that the first causes a termination of the transfer, while the latter not, but maybe it would be better to detail in which cases TransferError could be used and how to interpret it.

TBD: Clearing House in Information Model

Resolve TBD in information.model.md.

Wrong ID in contract-negotiation.json

The contract negotiation has an @id and dspace:processId. The second one should be the correlationId (comparable to the transfer process).

Renaming "IDS Communication Guide V2"

As discussed in the meeting on 2.2.2023, would be great to find an alternative name.
Some keywords to take into consideration:
dataspace, protocol, standard.

Changing HTTP Statuscode from 200 to 204 for endpoints with not defined response bodies

In the specification for the HTTP-Bindings of the Contract Negotiation and TransferProcess exists some endpoints with no specified response body. (Endpoints are listed at the bottom, Contract Negotiation, Transfer Process)
A clean solution is to introduce an empty response body and change the expected status code from 200 to 204.

Contract Negotiation Provider:
negotiations/:id/request
negotiations/:id/events
negotiations/:id/agreement/verification
negotiations/:id/termination

Contract Negotiation Consumer:
negotiations/:id/offers
negotiations/:id/agreement
negotiations/:id/events

Transfer Process:
transfers/:id/start
transfers/:id/completion
transfers/:id/termination
transfers/:id/suspension

Rename CatalogErrorMessage to CatalogError

Align with error for negtiation and transfer

CN binding is missing termination endpoint for consumer

The contract negotiation protocol states that a termination message can be sent by provider or consumer. The HTTP binding is missing the termination endpoint on consumer side.

https://w3id.org/dspace/v0.8/context.json is a 404

@context link https://w3id.org/dspace/v0.8/context.json is a 404 error. is it right?

Scalability issue with missing feature to request "all offers for a known asset ID"

After receiving access to the repo last week, I'm now trying to dig deeper into the protocol spec. One question I have is regarding scalability of requests when the AssetId is already known. In the 'old' specification I understood, that it was part of the IDS protocol to request 'all offers for 1 asset' with adding the 'requestedEelment' to the request to the catalog service.

Ref:
https://github.com/International-Data-Spaces-Association/IDS-G/tree/main/Communication/sequence-diagrams/data-connector-to-data-connector

With the 'new' spec, it looks to me like this part is 'outsourced' to the implementation part with the very general 'ids:filter' expression
https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/catalog/message/catalog.request.message.json

I would see this as a very crucial part for scaling. Catalogs can become VERY big. Transferring the whole content even if the requester already knows the asset id is a problem. And outsourcing this scalability critical part should not be desired from my perspective.

My proposal is NOT to define all filters in IDS, but specify a way to 'filter' for one specific assetId only.

Any thoughts on this? Unfortunately I can not join the Thursday meeting this week because of a Catena-X Workshop. Maybe you can comment here if you have thoughts on this.

Thanks in advance,
Matthias Binzer

Which version number will we present at March 8th

We should indicate a version number of this for March 8th

Relationship between Usage Control and Access Control

As a reminder to what we discussed during the sync call 2 weeks ago. Is Access Control really part of Usage Control?

Seems to appear in multiple documents, e.g.
https://internationaldataspaces.org/wp-content/uploads/dlm_uploads/IDSA-Position-Paper-Data-Sovereignty-Requirements-Analysis-of-Manufacturing-Use-Cases.pdf
Page 10.

It should be discussed whether:

"Usage control is an extension to traditional access control"

should be changed to:

"Usage control is an *addition* to traditional access control"

for more clarity.
I think "extension could be still fine, if not the picture would direct into the idea that one was "contained in" the other.

Add transitions to state TERMINATED

From the state diagrams, without additional text, it is not possible to derive from which states one can get into TERMINATED

Define type of ids:code

currently an undefined Object

Dataset.odrl:hasPolicy 1:1 or 1:N?

As described in here:
https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/catalog/catalog.protocol.md#311-odrlhaspolicy

An asset entry Dataset must have 1..N hasPolicy attributes that contain an ODRL Offer

all the examples I could find did NOT contain a list, e.g.
https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/catalog/message/example/dcat.distribution.example.json#L17

but only a single policy/offer.

Also from ODRL or Dcat, I could not understand that this is a list. Can we reference the 'upstream' source that odrl:hasPolicy can be a list - or if this is a specific 'Dcat profile' change, it should be listed as such here I guess:
https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/catalog/catalog.protocol.md#5-dcat-and-odrl-profiles

Define ids:DataPlaneType

TransferRequestMessage is referring to a data exchange format that we, as example, set to an IDS enum. We need to have further discussions to come to a decision about that. Should the IDSA predefine transfer protocols or should adopters/users of this protocol agree on existing standards/be free to define new ones?

Remove comments

Comments should be removed as they are rendered by GitBook

TBD: Versioning

Resolve TBD in catalog.binding.https.md.

RFC: Introduce a 'Policy Repository'

I want to kindly ask to give feedback regarding the following proposal:

Example snippet from the catalog example:

      "odrl:hasPolicy": [ 
        {
          "@context": {
            "@vocab": "https://www.w3.org/TR/odrl-model/"
          },
          "@id": "urn:uuid:2828282:3dd1add8-4d2d-569e-d634-8394a8836a88",
          "permission": [
            {
              "action": "use",
              "constraint": [
                {
                  "leftOperand": {
                    "@value": "spatial"
                  },
                  "rightOperand": {
                    "@value": "EU"
                  },
                  "operator": "EQ"
                }
              ],
              "duty": []
            }
          ],
          "prohibition": [],
          "obligation": []
        }
      ],

https://raw.githubusercontent.com/International-Data-Spaces-Association/ids-specification/71f06f718147f12a4d333e9a9e604d13944882b1/catalog/message/catalog.json

Since this is very redundant, because many of those policies / offers are very similar, I think it would be also allowed to use IDs as a reference instead of the entire node of the object, meaning:

"odrl:hasPolicy": [
    {
        "@type": "odrl:Offer",
        "@id": "https://provider.com/edc/offer/1",
   },
   {// next possible policy }
],

At least that is my - still limited - understanding of:
https://www.w3.org/TR/vocab-dcat-3/#conformance

Additional constraints in a profile MAY include:
Controlled vocabularies or IRI sets as acceptable values for properties

and if this is the case, I would even slightly change the id of the policy and make it a "content addressable storage" by using the hash of the policy itself (as a URL) to reference it. So it would look like:

"odrl:hasPolicy": [
    {
        "@type": "odrl:Offer",
        "@id": "https://provider.com/policies/cdfd26aaf5b1fdc6d71af7c1349869f9314b67626bc1eec44e64af674e357eed",
   },
   {// next possible policy }
],

where the cdfd26aaf5b1fdc6d71af7c1349869f9314b67626bc1eec44e64af674e357eed is a sha256 hash of the policy itself. Serialization / canonicalization details need to apply of course.

That means there would be a new endpoint containing all possible policies: a policy repository under /policies/{hash}

The only way that this is possible at all, is because of the separate profile which says:
https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/catalog/catalog.protocol.md#5-dcat-and-odrl-profiles

Each ODRL Offer must NOT include an explicit target attribute.

because hashing the policy WITH a target wouldn't work :-)

The advantages would be:

• Reduce data transfer, assuming many datasets use the same policy
• Reduce processing overhead (on both sides, but mainly) on the consumer side, because it's immediately clear whether the policy is already known and can be accepted (allow-listed policies...)
• uniqueness of policies may allow some further optimizations during the flow

Possible DISadvantages:

• Are policies protected content already? And is the hash 'unique' enough to 'protect' its content? Further access control could be applied, too, but probably is not worth it. I guess it's better to add the full policy to the dataset instead of a reference if there are concerns. Can be decided per dataset of course.

Any thoughts on this?

docs: Fix unclear security properties of "security tokens"

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.

Fix dataset reference in the Catalog Protocol specification

The dataset reference in catalog/catalog.protocol.md needs to be fixed:

Response: Dataset containing the DCAT Dataset.

per @sebbader:

The data object in 2.2 is a dcat:Catalog, not a dcat:Dataset. Even though dcat:Catalog inherits from dcat:Dataset, I guess we need an own schema for it.

Unneeded `correlationId` attribute in the `TransferProcess` messages

The TransferProcess messages bring, in addition to processId, a correlationId, that, in fact, it is not needed:
as done in the ContractNegotiation, the processId will represent a correlation id that could be used by both parts to identity the same CN/TP. It will be enough for the scope.

What is the difference between 'Usage Policy' and License?

Since Usage Policies is the 'new' part of what IDS is capable of doing, I think it needs to be explained how it relates to 'licenses' like e.g. 'Creative Commons' and other, also proprietary licenses (paper contracts).

Opinions on that?

Update figure and renaming data connector to connector

          I would argue against the name "data connector".. I know "data space/dataspace connector" is bad because of all the projects etc. but these documents are not specifying data standards, transfers etc. Rather, the connector is adding data space communication and trust concepts into IT landscapes. We are defining connectors for a data space supporting a data space protocol and doing data space stuff. WDYT? (also referring to the figure introduced with this PR)

Originally posted by @juliapampus in #24 (comment)

Explain "IRI"

In the contract negotiation specification it's stated that

ids-specification/negotiation/contract.negotiation.protocol.md

Line 17 in 3f9fc7c

A CN is uniquly identified through an IRI. Each CN requires a newly generated IRI, which may not be used in a CN after a terminal state has been reached.

But it's not explained what an IRI is, I looked in all the repository but cannot find anything related.
Maybe it's just a typo of URI

Why `ContractNegotiation` states report `PROVIDER` and `CONSUMER` while `TransferProcess` ones not?

Looking at the specifications, for transfer process states are:

ids-specification/transfer/transfer.process.protocol.md

Lines 57 to 63 in 3f9fc7c

	The TP states are:
	- **REQUESTED** - An asset has been requested under an `Agreement` by the consumer and the provider has sent an ACK response.
	- **STARTED** - The asset is available for access by the consumer or the provider has begun pushing the asset to the consumer endpoint.
	- **COMPLETED** - The transfer has been completed by either the consumer or the provider.
	- **SUSPENDED** - The transfer has been suspended by the consumer or the provider.
	- **TERMINATED** - The transfer process has been terminated by the consumer or the provider.

While for contract negotiation are:

ids-specification/negotiation/contract.negotiation.protocol.md

Lines 21 to 31 in 3f9fc7c

	The CN states are:
	- **CONSUMER_REQUESTED** - A contract for an asset has been requested by the consumer based on an offer and the provider has sent an ACK response.
	- **PROVIDER_OFFERED** - The provider has sent a contract offer to the consumer and the consumer has sent an ACK response.
	- **CONSUMER_AGREED** - The consumer has accepted the latest contract offer and the provider has sent an ACK response.
	- **PROVIDER_AGREED** - The provider has accepted the latest contract offer, sent an agreement to the consumer, and the consumer has sent an ACK response.
	- **CONSUMER_VERIFIED** - The consumer has sent an agreement verification to the provider and the provider has sent an ACK response.
	- **PROVIDER_FINALIZED** - The provider has sent a finalization message including his own agreement verification to the consumer and the consumer has sent an ACK response. Data is
	now available to the consumer.
	- **TERMINATED** - The provider or consumer has placed the contract negotiation in a terminated state. A termination message has been sent by either of the participants and the
	other has sent an ACK response. This is a terminal state.

Is there a reason why on contract negotiation the states strictly related to consumer activities are marked with the CONSUMER_ prefix and the provider ones with PROVIDER_ while in the transfer process this convention is not used?
In fact TransferProcess REQUESTED is representing a consumer activity, while STARTED is representing a provider action.

I would propose to remove these prefix from the Contract Negotiation states where the part that triggered it, e.g.:

• REQUESTED - (the consumer requested a negotiation)
• OFFERED - (the provider offered a negotiation)
• VERIFIED - (the consumer verified the negotiation)
• FINALIZED - (the provider finalized the negotiation)

while the CONSUMER_AGREED and PROVIDER_AGREED are the only states that effectively need the prefix.

Inconsisency in `transfer.process.protocol.md`

In two different parts of the transfer.process.protocol.md there are two clashing sentences.

First, it's stated that a consumer could issue a TransferRequestMessage

ids-specification/transfer/transfer.process.protocol.md

Lines 43 to 46 in a98e3d4

	#### Pull Transfer
	A pull transfer is when the consumer data plane initiates retrieval of asset data from a producer endpoint. For example, after the consumer has issued an `TransferProcessStart,`
	message, the consumer requests the data from the producer-specified endpoint.

But then seems that only the provider can send it:

ids-specification/transfer/transfer.process.protocol.md

Lines 113 to 119 in a98e3d4

	### 2. Transfer Start Message
	
	**Sent by**: Provider
	**Resulting State**: STARTED

My guess is that only the provider should be able to start a transfer, because, as seen in the state machine diagram, the consumer "requests" it, and the provider "starts" it

Focus on "data access" or "data usage" contracts?

From the introduction:

How contract agreements that govern data access are syntactically expressed and electronically negotiated.

could this be changed into maybe

How contract agreements that govern data access AND/OR data usage are syntactically expressed and electronically negotiated.

The question behind might be a bit larger:
During discussions I learned that negotiated agreement should eventually replace existing legal ("paper") contracts. If we follow this picture, we need to ask what is the granularity of those "paper" contracts today.
Example:
A supplier produces LED lights of a certain type, let's say 'FancyLedLight'. the supplier produces 1 Billion of those things and each get a serial number 00000...1 00000...2 and so on.

Do we create and negotiate an agreement for each and every serial number? If not, and we say we create 1 an asset for the type (FancyLedLight) because the policies is the same for all of those produced 'instances' of the part, we might get additional access decisions in the data source / backend system (e.g. based on the requester's identity). In such a use case, the clear benefit is the negotiated usage policy, BUT access needs to be handled separately / additionally, e.g. attribute based (ABAC) with additional information from e.g. a sales database.

I hope the slightly longer example helps to explain my question :-)

Missing details in `Transfer Completion Message`

The Sent by and Resulting state are empty

ids-specification/transfer/transfer.process.protocol.md

Lines 159 to 161 in a98e3d4

	**Sent by**:
	**Resulting State**:

Add details for TransferTerminationMessage

Provide more content in transfer.process.protocol.md.

Provide OpenApi definition of https bindings

catalog.binding.https.md says:

The OpenAPI definitions for this specification can be accessed here.

Would be a nice idea to have an OpenApi definition of the HTTPS bindings.

Same goes for negotiation and transfer.

Clarify the Attributes of the ContractNegotiationTerminationMessage

Neither the descriptions at https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/negotiation/contract.negotiation.protocol.md#5-contractnegotiationterminationmessage or the example contain enough details for the attributes ids:code or ids:rejectionReason.

Maybe we need a new enum for ids:code and/or a new class for the ids:rejectionReason, including a description or explanation field.

ContractRequestMessage 'target' in negotiation process required or redundant?

In the catalog process, the profile explicitly says:

Each ODRL Offer must be unique to a dataset since the target of the offer is derived from its enclosing context.
Each ODRL Offer must NOT include an explicit target attribute.

https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/catalog/catalog.protocol.md#5-dcat-and-odrl-profiles

How is this during the negotiation process?
The example message for ContractRequestMessage shows both, a "dspace:dataSet": "urn:uuid:3dd1add8-4d2d-569e-d634-8394a8836a88" and a dspace:offer -> odrl:target which is the same and probably is always the same, right?
https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/negotiation/message/contract-request-message.json

---

Matthias Binzer
Robert Bosch GmbH

Clean up repo

• Consistent file naming
• Consistent directory structure:

message
- schema
- diagram
- example

• Fix SUMMARY.md
• Fix typos, word highlighting

Cross data space communication "in scope"?

I also learned that the cross data space communication is out of scope (at least for the major implementation EDC) and therefore it seems to me important to explicitly point this out in the Introduction, whether cross data spcace communiction is in scope or out of scope for the IDS protocol specification.
https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/README.md

did:web as the ONLY allowed did method?

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 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).
https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/model/information.model.md

We should not allow-list only did:web but leave it open towards the dataspace to define which did method (did:*) is allowed.

"Data Plane" or generally the actual data transfer needs to be explicitly set out of scope

As I understood, the part (edc speak) of data planes is out of scope for the specification. As I also learned (outside of IDSA) this is not clear to everyone. Therefore, this needs to be emphasized in the introduction to make this an explicit statement.

https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/README.md

Rename contract.negotiation.error.message.json

Rename to contract.negotiation.error as this object could provide detailed information about failing requests but should not be treated like a message.

Cleanup shapes

Some properties from the .json and .puml are missing in the .ttl files or are inconsistent regarding types.

Errors are not a subClass of a message but of an error.

Split `ContractNegotiationEventMessage`

In the contract negotiation specs there's a message that's used for two different scopes:

ids-specification/negotiation/contract.negotiation.protocol.md

Lines 151 to 179 in 3f9fc7c

	### 5. ContractNegotiationEventMessage
	
	**Sent by**: Provider or Consumer
	**Resulting State**: PROVIDER_FINALIZED, CONSUMER_AGREED, TERMINATED
	**Example**: [ContractNegotiationEventMessage](./message/contract-negotiation-event-message.json)
	**Response**: OK or ERROR
	**Schema**: [ContractNegotiationEventMessageShape](./message/shape/contract-negotiation-event-message-shape.ttl) and the [ContractNegotiationEventMessage JSON Schema](./message/schema/contract-negotiation-event-message-schema.json)
	#### Description
	When the `ContractNegotiationEventMessage` is sent by a provider with an `eventType` property set to `FINALIZED`, a contract agreement has been finalized and the associated asset
	is accessible. The state machine is transitioned to the `PROVIDER_FINALIZED` state. Other event types may be defined in the future. A consumer responds with an error if the signature
	can't be validated or is incorrect.
	It is an error for a consumer to send a `ContractNegotiationEventMessage` with an eventType `finalized` to the provider.
	When the `ContractNegotiationEventMessage` is sent by a consumer with an `eventType` set to `ACCEPTED`, the state machine is placed in the `CONSUMER_AGREED` state.
	It is an error for a provider to send a `ContractNegotiationEventMessage` with an eventType `ACCEPTED` to the consumer.
	Note that contract events are not intended for propagation of agreement state after a contract negotiation has entered a terminal state. It is considered an error for a consumer or
	provider to send a contract negotiation event after the negotiation state machine has entered a terminal state.

Why not splitting it into two more self-explaining messages like:
ControlNegotiationFinalizeMessage (sent by the provider to the consumer)
ControlNegotiationAcceptMessage (sent by the consumer to the provider)

Typo in `transfer.process.protocol.md`

I think the phrase should be:

A TransferError is different to an error response. A TransferError does not necessarily finish the transfer but it can continue afterwards.

ids-specification/transfer/transfer.process.protocol.md

Line 209 in a98e3d4

- A _TransferError_ is different to an error response. A _TransferError_ does not necessarily finish the negotiation but can continue afterwards.

Usage of Term Information Model

We might want to change the term Information Model in this spec to avoid confusion and to be more precise.

• The term Information Model was used in IDS before and is used for the ontology representing the Information Layer of the IDS-RAM
• From my perspective it is not an information model, but more a structural model that describes the entities and their relationship in a data space.
• The term information model addressed more the domain of data engineering (at least referring to Wikipedia). The term conceptual model would represent better the scope of the model, as we do not describe a data model, but more the relationships of the different entities or concepts in data space (also Wikipedia.

DCAT Schema and Shape is incomplete

The JSON schema file at https://github.com/International-Data-Spaces-Association/ids-specification/blob/main/catalog/message/schema/catalog-schema.json only contains a few attributes. Full DCAT compliance requires also the missing ones. Same for the Shape file.

Evaluate usage of dct:description

Introduced for some classes. Could this be used for every?

IDS Namespaces

The IDS Information Model introduced two main namespaces, ids (long: https://w3id.org/idsa/core/) for the classes and properties (aka. 'T-Box') and idsc (long: https://w3id.org/idsa/code/) for instances (aka. 'A-Box'). This separation is not sufficient anymore as:

1. Parts of the ids namespace will be in the scope of this specification, other parts not. Reviewing the protocol specification is therefore very hard.
2. The schemas (shapes) have an additional one (shapes: https://github.com/International-Data-Spaces-Association/InformationModel/tree/master/testing/). I'd even say this namespace is more a technical dept...
3. Versioning is not really thought through yet.

Trust dimension of Data Connector interactions

I would like to try to map the protocol discussion and focus with my personal view of the world:

Trust setup and negotiation in the IDS (or other data spaces) - Connector centric view

Introduction

To establish trust into data exchange processes, several means of secure deployment, security features and certification aspects can be facilitated:

• Secure deployment in a Trusted Execution Environment such as AMD SEV-SNP or Intel SGX (TDX).
  • Verification via Remote attestation of trust properties towards external parties.
• Establishment of Secure Boot via TPM
  • Verification via Remote attestation of trust properties towards external parties.
• Verification of the issued certification level (Such as C5 cloud certification) by verifying the identity properties of a service.
• Storage of data on encrypted volumes, storing private keys in HSMs, ...

These means need to be facilitated to establish trust between parties. We assume the data transaction relationships as sketched in the next section:

##Assumed data workflow / component interaction

1. An Identity Provider (IdP) issues trust related claims to IDS Connector. In IDS context, this is currently the combination of CA and DAPS. Trust related claims are issued by the DAPS.
2. Data Connector A is looking for specific data. Metadata includes:

• Data characteristics.
• Contract conditions (e.g., C5 cloud certification, execution environment preconditions)
• Connector address offering data offering (Data Connnector B)
• Owner

3. Both parties negotiate a usage contract. This could include:

• "Only process on a specific container or processing context"
• "Only process in a Trusted Execution Environment"
• "Do not forward to another party"

4. Both connectors set up the data workflow
5. Data is exchanged.

Trust implications

Several implications arise fom this:

1. Both parties trust the same IdP (no matter of how centralized or de-centralized). So we have a trust relationship between Connector A/B and the IdP.Identity claims such as certification level or hardware trust anchor support need to be verified between both Data Connectors.
2. Metadata is potentially untrusted. Metadata and identity claim validation has to be done between Data Connectors.
3. Both Data Connectors trust that the other parties Data Connector is "trustworthy":

• Both Data Connectors are deployed in a secure deployment environment.
• Both Data Connectors are configured properly.
• Both Data Connectors are not tampered with.

4. Data Connectors configure data sink and data source to grant access and acquire data for the specified data workflow. Data Connectors have privileged access to data sink and data source. (Remark: This is why in the IDS concepts, we have an overarching trust entity between data services and the Connector Core Services and see this overarching entity as a "Connector".)
5. Data Service associated with Data Connector A consumes data Data Service defined by Data Connector B. This second trust relationship requires verififcation of negotiated trust properties between services.

Proposal for trust integration

The current protocols are useful and needed. However, trust is omitted from the discussions so far. We believe that trust implication are associated with every step as discussed above. The specification so far is deliberately abstract. But we believe that these topics should at least be addressed in an explanatory section stating that these topics need do be defined in another spec. At some point, some extensions or detailing needs to be done:

1. Trust related claims need to be verified on Control plane level as well as Data plane level, since both are involded in trustworthy data transer setup and data exchange.
2. Trust negotiation needs to be part of Data Connector contract negotiation.
3. Trust negotiation needs to be part of the Data Plane interaction.

I would be happy to hear your thoughts.

Add details for TransferSuspensionMessage

Provide more content in transfer.process.protocol.md.

Distributed execution, policies

Hi,

Apologies in advance, this is not the right place to put this, but it's all I have access to and it seems the right people will read this if I post it here. Please contact me by email (see below) rather than replying here, and perhaps the maintainers would be so kind as to delete this issue when we have established contact?

I joined the Dataspace Protocol Preview session on Thursday, and asked some questions. Thanks! It was very enlightening.

For the past couple of years, I've been working on a design for a federated data sharing system, intended primarily for data analytics but otherwise fairly similar to IDS in its goals of user sovereignty, flexibility, scalability, and interoperability. It has policies (specific ones, with an algorithm for interpreting them) and distributed execution (for compute-to-data, trusted third party, federated learning, etc.) as well as data downloads.

If that sounds interesting, I have a preprint (to be published open access) at https://arxiv.org/abs/2210.17155, and a proof-of-concept at https://github.com/SecConNet/mahiru (Apache License 2.0). Being a proof-of-concept it's not as user-friendly as my other software, but if you want to try to run it, this is where to start: https://github.com/SecConNet/mahiru/blob/develop/docs/distributed_scenarios.rst. For lack of user interfaces it's not spectacular however, so the paper is probably what you want.

You can contact me at l dot veen at esciencecenter dot nl if you have questions or would like to talk.

Thanks,

Lourens

Add missing diagram for ids:ContractOfferMessage

.png and .puml missing

Improving findability of files

The json files are not rendered by GitBook, Some overview would be good to discover all releated files