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

[matgnt]

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

[matgnt]

During the meeting today we agreed that we need to add a sentence to differentiate between "access" to the contract negotiation details (assets, etc) and the actual data access.
I'll add a more detailed proposal here soon...

[jimmarino]

The statement could be changed to:

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

However, I think we should be clear about the above example. First, a distinction should be made between "data access" and "access control."

My further $.02:

1. The specification should not include details about "access control" since that is an implementation detail and also specific to the data space. For example, a provider may choose to reveal all of its assets (data sets) in a catalog without access control, or it may implement some form of access control that restricts viewing parts of a catalog to a subset of clients. Further, a catalog endpoint may support access control for its catalog, which is an implementation detail that we should not standardize.

2. The specification should not assert anything about the relationship between a "contract agreement" and a legal framework - that is up to a dataspace authority to determine.

3. The specification should not assert best practices for modeling assets or contract negotiations (a separate primer could). For example, in the use case where a provider wants to share data covering millions of parts, it would not make much sense to model those as individual assets. Instead, it would probably be better to model the parts as a single asset (or a limited number of assets) and allow the client to request specific parts via the data plane after a contract agreement has been negotiated. The spec, however, should not be prescriptive in this way since it only deals with normative conformance.

[matgnt]

Should we add an additional sentence like:

Data Access does not mean 'access control'. Data Access means making data accessible in a way that it can be found and negotiated.

this could be right below the numbered list or we make it part of the numbered list.

Maybe even additionally:

Access control is up to the dataspace to define.

[jimmarino]

SGTM

[PeterKoen-MSFT]

should we maybe introduce the term data discoverability to differentiate those ?
One of them is a discoverability control, the other one is an access control.
Or would this term confuse people to much?

[jimmarino]

I would stick with “access control” because it is a common term. Jim

…

On Feb 22, 2023 at 11:58:40 AM, Peter Koen ***@***.***> wrote: should we maybe introduce the term data discoverability to differentiate those ? One of them is a discoverability control, the other one is an access control. Or would this term confuse people to much? — Reply to this email directly, view it on GitHub <#32 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC4H4OZZJMS6THUDH6PXMDWYXWOBANCNFSM6AAAAAAU53Z45Y> . You are receiving this because you commented.Message ID: <International-Data-Spaces-Association/ids-specification/issues/32/1439819785 @github.com>

[PeterKoen-MSFT]

result from the discussion on our call:
How contract agreements that govern data usage are syntactically expressed and electronically negotiated.

Add a term to the terms and definitions document: For the "access control" to metadata of data assets we will use "discoverability", to clearly distinguish it from access control to the data asset. Implementation specific details of discoverability will not be defined in this specification but is up to the dataspace to define (e.g. can you see all metadata and only negotiate contracts on specific ones, or can you see only those data asset metadata where you also have the right to negotiate a contract?)

[arnoweiss]

This appears to remain relevant as neither "access control" nor "discoverability" have been added to the terms [1].

[1] https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol/overview/terminology

[PeterKoen-MSFT]

access control and discoverability are generic and common terms in IT and for developers. I don't think that we need to add those to the IDSA specific terminology.