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

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.

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

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 :-)

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?

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.

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.

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.

Resolve TBD in information.model.md.

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

The Sent by and Resulting state are empty

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

But then seems that only the provider can send it:

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

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

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.

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

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.

currently an undefined Object

In the contract negotiation specification it's stated that

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

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.

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.

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.

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.

Looking at the specifications, for transfer process states are:

While for contract negotiation are:

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.

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.

          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)

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.

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

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

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.

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?

Align with error for negtiation and transfer

• Consistent file naming
• Consistent directory structure:

message
- schema
- diagram
- example

• Fix SUMMARY.md
• Fix typos, word highlighting

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

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

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

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

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

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

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)

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

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.

Resolve TBD in catalog.binding.https.md.

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

.png and .puml missing

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?

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.

Comments should be removed as they are rendered by GitBook

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

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.

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

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