Skip to content

Latest commit

 

History

History
77 lines (52 loc) · 6.02 KB

model.md

File metadata and controls

77 lines (52 loc) · 6.02 KB

2 Dataspace Model

2 Dataspace Information Model

The following sections outline the Dataspace Information Model, which form the foundation of this specification.

2.1 Dataspace Entity Relationships

The relationships between the primary dataspace entities are defined as follows:

Note that all relationships are multiplicities unless specified.

  • A Dataspace Authority manages one or more Dataspaces. This will include participant registration and may entail mandating business and/or requirements. For example, a Dataspace Authority may require participants to obtain some form of business certification. A Dataspace authority may also impose technical requirements such as support for the technical enforcement of specific usage policies.
  • A Participant is a member of one or more Dataspaces. A participant registers Participant Agents that perform tasks on its behalf.
  • A Participant Agent performs tasks such as publishing a catalog or engaging in an asset transfer. In order to accomplish these tasks, a participant agent may use a verifiable presentation generated from a credential obtained from a third-party issuer. A participant agent may also use an ID token issued by a third-party identity provider. Note that a participant agent is a logical construct and does not necessarily correspond to a single runtime process.
  • 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 types and semantics of ID tokens are not part of this specification. An identity provider may be a third-party or a participant itself (for example, in the case of decentralized identifiers).
  • A Credential Issuer issues verifiable credentials used by participant agents to allow access to assets and verify usage control.

The diagram below depicts the relationships between ParticipantAgent types:

  • A CatalogService is a Participant Agent that makes a DCAT Catalog available to other participants.
  • A Catalog contains one or more Asset Entries, which are DCAT Datasets. A Catalog also contains at least one DCAT DataService that references a Connector where assets may be obtained.
  • An Asset Entry has one Offer, which is an ODRL Offer describing the usage control policy associated with the asset.
  • A Connector is a Participant Agent that performs Contract Negotiation and Asset Transfer operations with another connector. An outcome of a ContractNegotiation may be the production of an Agreement, which is an ODRL Agreement defining the usage control policy agreed to for an asset.

2.2 Classes

Not all dataspace entities have a concrete technical materialization; some entities may exist as purely logical constructs. For example, a Dataspace Authority and Participant Agent have no representation in the protocol message flows that constitute dataspace interactions. This section outlines the classes that comprise the concrete elements of the model, i.e. those that are represented in protocol message flows.

Note 1: The classes and definitions used in the dataspace protocol are reused from different standards and specifications as much as possible, in particular, DCAT and ODRL. As, however, the external definitions allow different interpretations or provide more attributes than required, the dataspace protocol is leveraging profiles of the original definitions rather than the complete original expressiveness. A profile in this sense is a restriction or subset of an external definition, enforcing that every occurance of an externally defined class is always conformant with the original definition. However, not every standard-compliant class might be compliant to the dataspace profile.

2.2.1 Catalog

A Catalog is a DCAT Catalog with the following attributes:

  • 0..N Asset Entries. Since a catalog may be dynamically generated for a request based on the requesting participant's credentials it is possible for it to contain 0 matching asset entries. (DCAT PROFILE)
  • 1..N DCAT DataService that references a Connector where assets may be obtained. (DCAT PROFILE)

2.2.2 Asset Entry

An Asset Entry is a DCAT Dataset with the following attributes:

  • 1..N hasPolicy attributes that contain an ODRL Offer defining the usage control policy associated with the asset. Offers must NOT contain any target attributes. The target of an offer is the asset associated with the containing asset entry. (ODRL PROFILE)
  • 1..N DCAT Distributions. Each distribution must have at least one DataService which specifies where the distribution is obtained. Specifically, a DataService specifies the endpoint for initiating a ContractNegotiation and AssetTransfer. (DCAT PROFILE)

2.2.3 Offer

An Offer is an ODRL Offer with the following attributes:

  • An ODRL uid is represented as an "@id" that is a unique UUID. (ODRL PROFILE)
  • The Offer must be unique to a dataset since the target of the offer is derived from its enclosing context.
  • The Offer must NOT include an explicit target attribute.

2.2.4 Agreement

An Agreement is an ODRL Agreement with the following attributes:

  • The Agreement class must include one target attribute that is the UUID of the asset the agreement is associated with. An agreement is therefore associated with EXACTLY ONE asset. (ODRL PROFILE)