PLASMA

Currently, the Solid protocol and its specifications lack the terms to express metadata related to the entities, roles, processes or infrastructure necessary to provide transparency to its data handling practices. In particular, these specifications do not have the terms to deal with the obligations and requirements brought by regulations related to (personal) data protection and privacy. The establishment of a metadata language such as PLASMA enables this by providing consistent taxonomies to describe the entities (e.g., providers, developers), the infrastructure, legal roles, policies, notices, registries and logs necessary to understand and establish responsibilities and accountability within the Solid ecosystem.

Vocabulary

PLASMA aims to provide a set of taxonomies to represent the most relevant concepts for representing information regarding the what, who, where, why, when and how data is being handled in the Solid ecosystem.

The Base concepts correspond to the core entities and infrastructure necessary to ensure accountability in the Solid ecosystem, namely the providers and developers of Solid Pods, apps, or services. In addition, a taxonomy of Policies and Agreements is provided to establish usage preferences and requirements of Solid users, as well as to establish data requests and record data agreements in a machine-readable format.

The Entities section provides a set of terms to describe the providers and developers of infrastructure, apps, services and identity, specifies different users in regards with their ability to interact with data, and describes agents as virtual entities that act of behalf of users, apps and services. Notices can be provided to describe these entities data handling activities.

A taxonomy of Services is also provided as this is a new concept introduced in the Solid ecosystem by PLASMA. The idea is to separate apps from other functionalities that might not be needed to be packaged as such, e.g., an identity verification service that checks the validity of identity certificates. A Data taxonomy is also specified to describe logs and metadata of data related with users, apps, services, and registries.

Base concepts

PLASMA relies on (and expands) the existing Solid specifications to specify its core concepts regarding providers, developers, Pods, apps or services. Later, these concepts are expanded into taxonomies of entities, policies, services, notices, and data.

App: An application that stores, collects, uses, shares, erases, or performs other actions on Data with the aim of providing specific purposes, services, or functionalities, e.g., a Contact Address Book or a Chess Game. An application can use several Services and requires human intervention.

In the Solid Application Interoperability specification, an application is defined as "a software-based Agent that a Social Agent uses to access, manipulate, and manage the data in their control, as well as the data they've been granted access to". This definition is compatible with the one provided for the same concept in the Solid Protocol specification. However, in PLASMA we do not specify Apps as a subclass of agents as both previously mentioned specifications do. Instead, as specified later on, PLASMA has the concept of AppAgent which specifies a type of agent that acts on behalf of an App.

Service: A functionality that may or may not utilise or interact with Data within a Pod. For example, an Identity Verification service that checks the validity of certificates, or a Query service that retrieves contacts matching the filter. A service can be associated with an App or a Pod and may not require human intervention, e.g. executing in the background. Services represent an abstraction of functionality that does not necessarily have to be packaged as an App. For example, Users can choose services to run on their Pods, with the services having their own Developers and Providers.
We envision service as being something that does not require the full metadata and agent-based identification and authorisation as an App. The exact mechanism for this as well as workflows for how it should be initiated and used have not been explored yet. We specify this concept to denote the possibility of having services separate from apps.
Pod: A Personal Data Store or a 'Pod' that conforms to the Solid specifications.

In the Solid Protocol specification, a Pod is defined as "a place for storing documents, with mechanisms for controlling who can access what". This definition is compatible with the one provided for the same concept in the Solid Application Interoperability specification, however, none of the Solid vocabularies provides this term.

Agent: A virtual entity associated with carrying out actions within or related to a Pod or its Data.

Both the Solid Protocol and Web Access Control specifications define an agent as a "person, social entity, or software identified by a URI; e.g., a WebID denotes an agent". The Solid Application Interoperability specification goes one step further by making a distinction between agents and social agents, where the latter is defined as a "strongly identifiable individual, group, or organization that can own or be responsible for data, and provide authorization to the access of that data by other Agents".

Policy: A set of guidelines or decisions or recommendations governing the use of Pod or its Data.
Entity: A legally recognised entity. Legally recognised means the entity has some recognition as being able to enter into agreements, has an address for accountability, is responsible for obligations, rights, etc. Entities are associated with Apps, Services or Pods.
Data: Data stored on a Pod or associated with User, App, Service, or DataSubject of a Pod.
Provider: An Entity that provides some thing such as a Pod, SolidPlatform, App, Service, or Data.
Developer: An Entity that develops some thing such as a Pod, SolidPlatform, App, or Service.
Customer: An Entity that has a business relationship with others entities to use Pods or related resources (e.g., purchasing, leasing, subscribing, or establishing any form of contract or agreement for the use of Solid Pods or its related resources, with or without monetary transactions).
SolidPlatform: The specific implementation of Solid that is installed or used within a Pod.
SolidSpecification: The specification that the Pod conforms to in terms of defining the terms, behaviour, and implementation details regarding Pods and their association with Services and Apps.

Related issue on providing terms for Solid Pod related entities and functionalities: solid/vocab/issues/83

Entities

Currently, Solid vocabularies do not provide terms to describe entities beyond the existing predicates in the WAC [] and ACP [] vocabularies to describe access conditions for agents, client applications or identity issuers. In PLASMA, we provide the terms to describe the providers and/or developers of Solid apps, services, and other Solid-related infrastructure, as well as terms to describe different types of users and agents.

Infrastructure

InfrastructureProvider: The Provider of infrastructure - such as storage, computing, network, domain names. The term infrastructure has a very specific and restricted meaning and should not be confused with other terms such as Services (e.g. analytics, querying) or Apps (e.g. data use dashboards).
PodProvider: The Provider of a Pod. Here the term provider refers to an entity that provisions the Pod, i.e. creates the necessary infrastructure, platform, and software so that the Pod can be used by the User.
PodDeveloper: The Developer of a Pod. The developer may not be the provider, in which case this term will differ from PodProvider.
SolidPlatformProvider: The Provider of a SolidPlatform. Here the term provider refers to an entity that provisions the SolidPlatform, i.e. creates the necessary infrastructure, platform, and software so that the SolidPlatform can be used by the User.
SolidPlatformDeveloper: The Developer of a SolidPlatform. The developer may not be the provider, in which case this term will differ from SolidPlatformProvider.

Applications

AppDeveloper: The Developer of an App. Developer here refers to the entity that developed the App, rather than individual members or units within the entity. For example, Firefox has Mozilla as the developer.
AppProvider: The Provider of an App. Here the term provider refers to the entity that enables that App to be accessed and used. The provider may not be the developer, in which case this term will differ from AppDeveloper. Examples include directly using an App from the developer's website (developer is same as provider), or using an App through an App Store or a common marketplace (developer is different from provider). For example, Firefox can be directly downloaded from its website, or via package management, or come pre-installed on a system.

The Solid Application Interoperability specification defines that an application should have an application profile document which is defined as a "linked data document obtained by dereferencing the URI for a given application identity". This document should be publicly readable (example below retrieved from the specification). In addition, this specification makes a distinction between strongly and weakly identifiable applications.

            PREFIX interop: <http://www.w3.org/ns/solid/interop#>

            <https://projectron.example/#id> a interop:Application ;
              interop:applicationName "Projectron" ;
              interop:applicationDescription "Manage projects with ease" ;
              interop:applicationAuthor <https://acme.example/#id> ;
              interop:applicationThumbnail <https://acme.example/thumb.svg> ;
              interop:hasAccessNeedGroup <https://projectron.example/needs#need-group-pm> .

Related issue on changing access needs from data to purpose-based needs: solid/data-interoperability-panel/issues/281

Services

ServiceDeveloper: The Developer of a Service. Developer here refers to the entity that developed the Service, rather than individual members or units within the entity.
ServiceProvider: The Provider of a Service. Here the term provider refers to the entity that enables that Service to be accessed and used. The provider may not be the developer, in which case this term will differ from ServiceDeveloper. Examples include directly using a Service from the developer's website (developer is same as provider), or using a Service through a Service Store or a common marketplace (developer is different from provider).

Identity

IdentityProvider: The Provider of an identity service or credential. Here provider means the entity that provisions the identity mechanism. For example, the IdentityProvider also provides an identity credential for use with the Pod.

The Solid terms vocabulary includes an oidcIssuer predicate to denote "a Solid OIDC Identity Provider capable of authenticating the WebID owner". Beyond that, no metadata is provided regarding the identity of the provider.

IdentityDeveloper: The Developer of an identity service or credential. The developer may be different from a provider, in which case this term will differ from IdentityProvider. For example, a PodProvider uses an existing certificate creation service to provide certificates, in which case the IdentityDeveloper would be the entity that created the certificate, while the IdentityProvider would be the provider of the identity.

Related issue on providing metadata regarding identity: solid/solid-oidc/issues/206

Related issue on supporting OIDC self-issuers: solid/solid-oidc/issues/91

Users

User: User of a Pod that can read, write, edit, erase data on a Pod. There may be multiple Users for a single Pod. Users can have limited permissions or abilities to interact with Data, for example - ReadUser that can only read or view data, or WriteUser that can only write or edit existing data.
DataSubject: The subject of Data within a Pod. The User may not always be the DataSubject. There may be multiple Subjects for a single Pod.
PodAdmin: User of a Pod that has administrative capability to make decisions about the Pod (separate from Data in a Pod), such as deleting the Pod, changing identity or other resource providers, or other controls and decisions related to the use and maintainence of Pods.
AdminUser: User of a Pod that has administrative capability to make decisions about Data on a Pod. The administration can scoped, such as being limited to specific data paths/categories, or can be global, i.e. applicable to all Data in the Pod.

Currently, Solid vocabularies do not make a distinction between different types of users. The term owner is used in several Solid specifications but not always with the same meaning. The Solid terms vocabulary is currently debating adding the concept owner to refer to the entity that has acl:control access to an entire storage. The Solid Protocol provides an informal extension of this definition by adding that an owner is "a person or a social entity that is considered to have the rights and responsibilities of a data storage" and "is set at storage provisioning time and can be changed". However, this term is problematic in that it may get interpreted as referring to data ownership which is a specific legally relevant concept, and may produce unintended applications in terms of copyright and intellectual property rights. It also creates issues through use of responsibilities which are based on legal obligations and rights, and which do not necessarily fall upon the individuals.

Related issue on adding new access modes: solid/web-access-control-spec/issues/85

Agents

Agents are entities that can act, whether by themselves (e.g. users), or on behalf or behest of other entities. They can be real (e.g. people, parents on behalf of children) or virtual (e.g. software agent). For Solid, we use Agent here to refer to the virtual agents so as to distinguish them from Entity which represents real or legal entities (i.e. those that can be held accountable).

UserAgent: An Agent acting on behalf of the User. For example, a Service running or managed by the Pod that assists the User by matching the DataRequest with UserPreferences and UserRequirements.
AppAgent: An Agent acting on behalf of an App. For example, an Agent that organizes an inbox application by email priority.
ServiceAgent: An Agent acting on behalf of a Service. For example, an Agent that syncs data stored in a Pod with another Pod.

The Solid Application Interoperability specification defines a specific type of application - an authorisation agent - appointed by a "Social Agent to be responsible for managing the access to data under their control" via registries. This definition is too narrow as a user might want to manage their pod data using other types of services or entities. Further details on the identity of this agent are currently missing.

Related issue on the usage of the Social Agent term: solid/data-interoperability-panel/issues/282

Policies

In the context of Solid, policies are documents used to specify the requirements of users, apps and services regarding data handling practices over data stored or shared through Solid Pods.

Note that these definitions are not limited to the data on Pod - this is intentional. Otherwise the policy will only relate to what is happening on the Pod, but not what happens after that. For example, to avoid cases such as to collect data for purpose X and then later decide to also perform purpose Y on it. This is to align the descriptions with legal requirements such as stating all purposes at the time of data collection, or going back and asking again for a new purpose.

DataRequest: Request from an App, Service, Agent or User to store, collect, use, share, erase, or perform other actions on Data.
AppManifest: Manifest from an App including information regarding startup parameters, identity, privacy policies and DataRequests.

While the W3C currently has a Web Application Manifest specification on the standardisation track, by itself it should not be considered sufficient for an App's Manifest in the context of Solid Pods. We envision the necessity to include metadata in the Manifest to denote information such as: entities, policies, identifiers, etc. -- related to accountability and legal compliance.

ServiceManifest: Manifest from a Service including metadata, Apps using the service and information regarding DataRequests.
UserPreference: Preference of a User regarding purposes, entities, and other actions on Data. A preference is a soft rule that may not be satisfied, e.g. when the user's preferences do not match the app's, the user can still decide to accept the stated purposes.
UserRequirement: Requirements of a User regarding purposes, entities, and other actions on Data. A requirement is a hard rule that should always be satisfied, e.g. the user requirement is to never share something - then even if the user accepts the stated request, this should not be allowed. One-time exceptions, or changing the rule, are solutions to get around this. But the intention is to create a barrier.
UserOffer: An offer from the User of a Pod regarding purposes, entities, and actions on Data. For example, the User expresses an UserOffer that their ServiceUsageStatistics as a category of Data is available for Research as a Purpose but only by NonProfitEntity (e.g. Universities), and with the requirement that it follows a specific Law (e.g. GDPR).
DataAgreement: An agreement regarding purposes, entities, and actions on Data. For example, stating that the User has given Consent to an App to Collect, Store, and Use some Data for a Purpose. Or, stating that the User has accepted that their Data will be Collected and Used for a providing a Service.

Agreements

An Agreement is a document that describes an arrangement between entities. In the context of Solid, an AppAgreement, ServiceAgreement or PodAgreement can be governed by a contract between the User and the entity responsible for the App, Service or Pod, or can be based on the UserConsent.

Currently, the Solid specifications do not include any information on such agreements - only resources related to authorised accesses are established between Users and Apps in the form of ACL authorisations or ACP access grants.

UserConsent: Agreement between a User and an Entity regarding the processing of Data in a Pod and based on the User's consent.
AppAgreement: Agreement between a User and an Entity regarding the processing of Data in a Pod and based on a contract between the User and the Entity having responsibility for the App.
ServiceAgreement: Agreement between a User and an Entity regarding the processing of Data in a Pod and based on a contract between the User and the Entity having responsibility for the Service.
PodAgreement: Agreement between a User and an Entity regarding the processing of Data in a Pod and based on a contract between the User and the Entity having responsibility for the Pod.

Notices

A Notice is a document to provide information about the entities, operations, data, location, etc. involved in a particular process. In the context of Solid, notices can be provided to declare the Providers/Developers of Apps, Services, infrastructure, to describe data processing practices, etc.

Notice: An artefact providing information about something.
ExAnteNotice: A Notice that is provided before something happens.
ExPostNotice: A Notice that is provided after something happens.
NoticeProvider: Entity that provides the Notice.
NoticeRecipient: Entity that receives the Notice.
NoticeContext: Information about a Notice, such as where/when/how/why it was provided.
AppPrivacyNotice: An App's privacy Notice.
ServicePrivacyNotice: A Service's privacy Notice.
PodPrivacyNotice: A PodProvider's or PodDeveloper's privacy Notice.
UserPrivacyNotice: A Pod User's privacy Notice regarding their Data.

Services

Services are processes or functionalities executed in the background, i.e., execution happens without an active front-end for the User to interact, that may or may not use Data stored within a Pod. Examples include identity management, querying or communication services. A Service can be an isolated process or can be associated with an App.

IdentityService: A Service providing identity credentials and identifiers.
LoggingService: A Service providing logging mechanisms and functionalities.
AccessControlService: A Service providing access control management and associated functionalities.
PolicyManagementService: A Service providing policy management and resolution functionalities.
IdentityManagementService: A Service providing identity management functionalities.
DataManagementService: A Service providing data management and associated functionalities.
NetworkManagementService: A Service providing network management and associated functionalities.
DataStorageService: A Service providing data storage and associated functionalities.
ComputeService: A Service providing computing and associated functionalities.
DataQueryService: A Service providing data querying and associated functionalities.
AppManagementService: A Service providing app management and associated functionalities.
ServiceManagement: A Service providing service management and associated functionalities.

Data

While Solid's overall purpose is to provide individuals with a data storage service for their Data, it should also contain (meta)data related with Users, Providers, Apps, Services, Logs or Registries.

Log: A provenance record associated with a process.

DataLog: A Log regarding actions on Data. For example, when data was added / stored in the Pod, when it was erased, accessed, or queried.
AccessControlLog: A Log regarding access actions on Data. For example, when data was permitted or denied to be accessed.
PolicyLog: A Log regarding Policies governing the Data. For example, a new user preference or requirement was added, or an app made a request, or a policy negotiation succefully took place and the user granted their consent.
IdentityLog: A Log regarding identity provision, verification, and its use. For example, an app's identity could not be verified, or a user successfully logged in.
SecurityLog: A Log regarding security concerns and incidents. For example, data integrity has failed a check, or there was an attempt to repeatedly access data without sufficient authorisation.

UserData: Data belonging or about the User.

DataProvider: The provider or source of Data. It can be made available by the User or a data provider or can be generated by an App, Service or Agent.
ResourceMetadata: Information about the Data contained in a Pod resource, e.g. resource A contains health data or resource B was updated by User X on date YYYY-MM-DD.

AppData: Data required by an App to provide its functionalities, or recording relevant contextual information.

AppMetadata: Information about an App such as who was its Provider, Developer, what functionalities and services it offers, relevant policies and authorisations.
AppLog: Logs related to an App's activities.
AppPersistentData: Data required by the App that is persistently stored. For example, results of a frequent query.
AppTemporaryData: Data required by the App that is temporarily stored. For example, results of a non-frequent query.

ServiceData: Data required by a Service to provide its functionalities, or recording relevant contextual information.

ServiceMetadata: Information about a Service such as who was its Provider, Developer, what functionalities and services it offers, relevant policies and authorisations.
ServiceLog: Logs related to a Service's activities.
ServicePersistentData: Data required by the Service that is persistently stored. For example, results of a frequent query.
ServiceTemporaryData: Data required by the Service that is temporarily stored. For example, results of a non-frequent query.

PodManagementData: Data required by a Pod to provide its functionalities. For example, storing the Pod metadata regarding Provider, Developer, PodAgreement, or credentials associated with Pod infrastructure.

SchemaData: Schemas, formats or shapes for the Data recognised or supported by Apps, Services or Pods.

Registry: An indexed record for providing collective and convenient access to Data within a Pod.

AccessControlRegistry: A Registry listing access control decisions and authorisations.
DataRegistry: A Registry listing data categories, resources, availability, and other relevant information.
DataSchemaRegistry: A Registry listing recognised or supported SchemaData for Pods, Apps, or Services.
PolicyRegistry: A Registry listing policies relevant to Data, Apps, Services, and Pod. For example, user preferences, consent decisions, pending requests.
AppRegistry: A Registry listing Apps associated with the Pod. For example, a contact book app along with its relevant metadata such as Provider, Developer, Policies.
ServiceRegistry: A Registry listing Services associated with the Pod. For example, a query service that can retrieve data along with its relevant metadata such as Provider, Developer, Policies.
UserRegistry: A Registry listing Users associated with the Pod and their relevant Policies, Agents, and other relevant information.

In the Solid Application Interoperability specification, only three types of registries are conceptualised, including an agent registry which encompasses both social agents and applications, an authorisation registry and a data registry where each data registration should comply with a data registration shape.

Using Policies

Currently, Solid has two specifications to determine access authorisations to resources in Solid Pods.

Web Access Control (WAC) specification: IRIs are used to represent resources and agents, and authorisation statements are stored within Access Control Lists (ACLs) defined per resource or inherited from the parent resource.
Access Control Policy (ACP) specification: access grants are provided to certain resources and agents based on an acp:Context that describes the agent's request for data and the access control resources (ACRs) that describe who is allowed or denied access to Pod resources using acp:Matchers.

Given that Solid provides a way for personal data to be stored and managed by individuals, it is important to consider the impact and application of data protection and privacy laws such as the GDPR that define specific concepts and obligations for how personal data can be collected, stored, used, and shared. In particular, GDPR's Articles 13 and 14 require that entities processing personal data provide transparent information on identity, purpose for processing, personal data categories, legal basis, recipients and so on, when they use personal data directly or indirectly obtained from individuals.

Neither WAC nor ACP provide the terms to deal with these requirements. To overcome this issue, PLASMA promotes the usage of the Open Digital Rights Language (ODRL), which is a W3C standard for policy expression and provides a convenient extension mechanism, through ODRL profiles, that can be integrated into the Solid architecture. Since ODRL is a general policy language, to invoke data protection-specific terms, the Data Privacy Vocabulary (DPV) can be used. DPV provides a rich set of taxonomies that can be used to specify purposes, personal data types, technical and organisational measures, rights, risks or entities. The ODRL profile for Access Control (OAC) [] already integrates these two resources to manage access control to Solid Pods' resources and uses ACLs access modes, i.e., acl:Read, acl:Write and acl:Append, when possible to express the level of access to be permitted or prohibited, as well as DPV's taxonomies to express policies over particular types of data, to express constraints over purposes, recipients or legal basis and so on.

The following sub-sections contain a set of examples that use OAC to specify UserPreferences, UserRequirements, UserOffers, DataRequests and DataAgreements as ODRL policies.

User Preferences

In this example, User A issued a preference policy https://example.com/preference1 that permits oac:Read access operations over its oac:Age data for the purpose of dpv:AcademicResearch if the legal basis is dpv:Consent.

<https://example.com/preference1> a oac:Preference, plasma:UserPreference ;
  odrl:profile oac: ;
  dct:description "Preference to read age data for academic research based on consent." ;
  dct:creator ex:userA ;
  dct:issued "2022-11-08T18:00:47"^^xsd:dateTime ;
  odrl:uid ex:preference1 ;
  odrl:permission [
    odrl:assigner ex:userA ;
    odrl:action oac:Read ;
    odrl:target oac:Age ;
    odrl:constraint [
      odrl:and 
        [
          dct:title "Purpose for access is to conduct academic research." ;
          odrl:leftOperand oac:Purpose ;
          odrl:operator odrl:isA ;
          odrl:rightOperand dpv:AcademicResearch
        ] ,
        [
          dct:title "Legal basis for access is consent." ;
          odrl:leftOperand oac:LegalBasis ;
          odrl:operator odrl:isA ;
          odrl:rightOperand dpv:Consent
        ]
    ]
  ] .

User Requirements

In this example, User A issued a requirement policy https://example.com/requirement1 that permits oac:Read access operations over its oac:Identifier data for the purpose of dpv:IdentityVerification if the legal basis is dpv:Consent.

<https://example.com/requirement1> a oac:Requirement, plasma:UserRequirement ;
  odrl:profile oac: ;
  dct:description "Requirement to read identifier data for identity verification based on consent." ;
  dct:creator ex:userA ;
  dct:issued "2022-11-08T18:05:09"^^xsd:dateTime ;
  odrl:uid ex:requirement1 ;
  odrl:permission [
    odrl:assigner ex:userA ;
    odrl:action oac:Read ;
    odrl:target oac:Identifier ;
    odrl:constraint [
      odrl:and 
        [
          dct:title "Purpose for access is to verify the identity of the assigner." ;
          odrl:leftOperand oac:Purpose ;
          odrl:operator odrl:isA ;
          odrl:rightOperand dpv:IdentityVerification
        ] ,
        [
          dct:title "Legal basis for access is consent." ;
          odrl:leftOperand oac:LegalBasis ;
          odrl:operator odrl:isA ;
          odrl:rightOperand dpv:Consent
        ]
    ]
  ] .

User Offer

In this example, User A issued an odrl:Offer with the identifier https://example.com/offer1, based on the requirement https://example.com/requirement1 and preference https://example.com/preference1 policies, as is indicated by the dct:source property. The permission associated with the requirement policy contains the property dpv:hasContext associated with the term dpv:Required to indicate that said permission is a requirement, while the term dpv:Optional is used to identify the rules related with a preference policy.

<https://example.com/offer1> a odrl:Offer, plasma:UserOffer ;
  odrl:profile oac: ;
  dct:description "Offer to read identifier data for identity verification and age data for academic research based on consent." ;
  dct:creator ex:userA ;
  dct:source ex:preference1, ex:requirement1 ;
  dct:issued "2022-11-08T18:07:34"^^xsd:dateTime ;
  odrl:uid ex:offer1 ;
  odrl:permission [
    dpv:hasContext dpv:Required ;
    odrl:assigner ex:userA ;
    odrl:action oac:Read ;
    odrl:target oac:Identifier ;
    odrl:constraint [
      odrl:and 
        [
          dct:title "Purpose for access is to verify the identity of the assigner." ;
          odrl:leftOperand oac:Purpose ;
          odrl:operator odrl:isA ;
          odrl:rightOperand dpv:IdentityVerification
        ] ,
        [
          dct:title "Legal basis for access is consent." ;
          odrl:leftOperand oac:LegalBasis ;
          odrl:operator odrl:isA ;
          odrl:rightOperand dpv:Consent
        ]
    ]
  ] ;
  odrl:permission [
    dpv:hasContext dpv:Optional ;
    odrl:assigner ex:userA ;
    odrl:action oac:Read ;
    odrl:target oac:Age ;
    odrl:constraint [
      odrl:and 
        [
          dct:title "Purpose for access is to conduct academic research." ;
          odrl:leftOperand oac:Purpose ;
          odrl:operator odrl:isA ;
          odrl:rightOperand dpv:AcademicResearch
        ] ,
        [
          dct:title "Legal basis for access is consent." ;
          odrl:leftOperand oac:LegalBasis ;
          odrl:operator odrl:isA ;
          odrl:rightOperand dpv:Consent
        ]
    ]
  ] .

Data Request

In this example, User B issued an odrl:Request with the identifier https://example.com/request1 to oac:Use oac:Age data for the purpose of conducting an academic research project X.

<https://example.com/request1> a odrl:Request, plasma:DataRequest ;
  odrl:profile oac: ;
  dct:description "Request to read age data for academic research." ;
  dct:creator ex:userB ;
  dct:issued "2022-11-08T18:15:56"^^xsd:dateTime ;
  odrl:uid ex:request1 ;
  odrl:permission [
    odrl:assignee ex:userB ;
    odrl:action oac:Use ;
    odrl:target oac:Age ;
    odrl:constraint [
      dct:title "Purpose for access is to conduct research in the academic project X, conducted in University Y." ;
      odrl:leftOperand oac:Purpose ;
      odrl:operator odrl:eq ;
      odrl:rightOperand ex:AcademicResearchProjectX
    ]
  ] .

ex:AcademicResearchProjectX a dpv:AcademicResearch ;
  rdfs:label "Conduct research in the academic project X, conducted in University Y." .

In this example, User A and B reach an agreement to allow oac:Read access operations over User A's Age data for the purpose of academic research in project X. This odrl:Agreement is the result of the matching of https://example.com/offer1 and https://example.com/request1, as indicated by the dct:references property. The legal basis of the agreement is consent, as is specified in the policy with the dpv:hasLegalBasis dpv:Consent terms, and User A and User B are registered as the data subject and data controller in question, respectively, using the dpv:hasDataSubject and dpv:hasDataController terms.

<https://example.com/agreement1> a odrl:Agreement, plasma:UserConsent ;
  odrl:profile oac: ;
  dct:description "Agreement to read age data for academic research based on consent." ;
  dct:creator ex:userA ;
  dct:issued "2022-11-08T18:13:37"^^xsd:dateTime ;
  odrl:uid ex:agreement1 ;
  dct:references ex:offer1, ex:request1 ;
  dpv:hasDataSubject ex:userA ;
  dpv:hasDataController ex:userB ;
  dpv:hasLegalBasis dpv:Consent ;
  odrl:permission [
    odrl:assigner ex:userA ;
    odrl:assignee ex:userB ;
    odrl:action oac:Read ;
    odrl:target oac:Age ;
    odrl:constraint [
      dct:title "Purpose for access is to conduct research in the academic project X, conducted in University Y." ;
      odrl:leftOperand oac:Purpose ;
      odrl:operator odrl:eq ;
      odrl:rightOperand ex:AcademicResearchProjectX ] ] .

Contract Agreement

In this example, User A and B reach an agreement to allow oac:Read access operations over User A's Contact data for the purpose of academic research project X. This odrl:Agreement is the result of the matching of https://example.com/offer2 and https://example.com/request2, as indicated by the dct:references property. The legal basis of the agreement is a contract, as is specified in the policy with the dpv:hasLegalBasis dpv:Contract terms, and User A and User B are registered as the data subject and data controller in question, respectively, using the dpv:hasDataSubject and dpv:hasDataController terms.

<https://example.com/agreement2> a odrl:Agreement, plasma:DataAgreement ;
  odrl:profile oac: ;
  dct:description "Agreement to read age data for academic research based on a contract." ;
  dct:creator ex:userA ;
  dct:issued "2022-11-14T01:11:29"^^xsd:dateTime ;
  odrl:uid ex:agreement2 ;
  dct:references ex:offer2, ex:request2 ;
  dpv:hasDataSubject ex:userA ;
  dpv:hasDataController ex:userB ;
  dpv:hasLegalBasis dpv:Contract ;
  odrl:permission [
    odrl:assigner ex:userA ;
    odrl:assignee ex:userB ;
    odrl:action oac:Read ;
    odrl:target oac:Contact ;
    odrl:constraint [
      dct:title "Purpose for access is to conduct research in the academic project X, conducted in University Y." ;
      odrl:leftOperand oac:Purpose ;
      odrl:operator odrl:eq ;
      odrl:rightOperand ex:AcademicResearchProjectX ] ] .

In order to comply with PLASMA, a set of conformance conditions is described in this section for Pod, app, service, user and agent conformance, specifically to specify what is mandatory to be provided, what is optional and how conformity should be assessed and ensured.

Pod Conformance

For a Pod to be conformant with this specification, the following conditions should be satisfied:

The requirements for Pod conformance necessitate shapes or forms to be developed for specifying information in a well-defined / commonly-agreed manner. This includes:

Shape for PodManagementData
Shape for AccessControlRegistry
Shape for PolicyRegistry
Shape for DataRegistry
Shape for DataSchemaRegistry
Shape for UserRegistry

A Pod MUST provide or declare PodManagementData which includes metadata about the Pod, such as InfrastructureProvider, PodProvider and SolidPlatformProvider and of its developers in case they differ from the providers, as well as the specific SolidPlatform and SolidSpecification implemented in the Pod and possibly a PodAgreement between the user and the entity having responsibility for the Pod.
example: pod-management-data
A Pod MUST implement or provide equivalent functionality to support the different registries and records/logs specified in this document, namely the AccessControlRegistry and PolicyRegistry, DataRegistry and DataSchemaRegistry.
examples: access-control-registry; policy-registry; data-registry; data-schema-registry
A Pod MAY have multiple users with varying degrees of control (shared Pods can be used to group data from private groups such as families or friends or within organisational environments such as departments or teams in a company). A record of the different users and their level of access MUST be kept in the UserRegistry.
example: user-registry
Pod discovery methods MAY be available for users wishing to make their data publicly available.

App Conformance

For an App to be conformant with this specification, the following conditions should be satisfied:

The requirements for app conformance necessitate shapes or forms to be developed for specifying information in a well-defined / commonly-agreed manner. This includes:

Shape for AppManifest
Shape for AppRegistry

All Apps SHOULD have an AppManifest in conformance with W3C Web Application Manifest specification.

The W3C App Manifest specification is not sufficient to provide the necessary information as required for legal accountability. Missing items include the app's providers and developer's legal identities, links to privacy notices and policies, etc.
App manifests MUST include infomation regarding the AppDeveloper and/or AppProvider.
AppManifest SHOULD state the DataRequest using odrl:hasPolicy either through internal triples or external links. The DataRequest should be checked for compliance to conformance with the ODRL profile for access control, e.g. example of a data request policy available in Section 3.4.
AppManifest SHOULD link the privacy policy of the app using dpv:hasPolicy either through internal triples or external links.
Shapes SHOULD be used to check conformance with mandatory manifest requirements.
example: app-manifest
App manifests of relevant apps MUST be stored in the AppRegistry.
Apps MAY have multiple AppAgents, which SHOULD be registered in the AppRegistry.
example: app-registry

Service Conformance

For a Service to be conformant with this specification, the following conditions should be satisfied:

The requirements for service conformance necessitate shapes or forms to be developed for specifying information in a well-defined / commonly-agreed manner. This includes:

Shape for ServiceManifest
Shape for ServiceRegistry

All Services SHOULD have a ServiceManifest.

A Service Manifest specification should be developed to provide the necessary information as required for legal accountability, including items such as the service providers and developer's legal identities, links to privacy notices and policies, etc.

Service manifests MUST include infomation regarding the ServiceDeveloper and/or ServiceProvider.
ServiceManifest SHOULD state the DataRequest using odrl:hasPolicy either through internal triples or external links. The DataRequest should be checked for compliance to conformance with the ODRL profile for access control, e.g. example of a data request policy available in Section 3.4.
ServiceManifest SHOULD link the privacy policy of the service using dpv:hasPolicy either through internal triples or external links.
Shapes SHOULD be used to check conformance with mandatory manifest requirements.
example: service-manifest
Service manifests of relevant services MUST be stored in the ServiceRegistry.
Services MAY have multiple ServiceAgents, which SHOULD be registered in the ServiceRegistry.
example: service-registry

User Conformance

For a User to be conformant with this specification, the following conditions should be satisfied:

The requirements for user conformance necessitate shapes or forms to be developed for specifying information in a well-defined / commonly-agreed manner. This includes:

Shape for IdentityLog
Shape for DataLog
Shape for AccessControlLog
Shape for PolicyLog
Shape for SecurityLog
Shape for UserRegistry

Impactful interactions of a User, such as logins, changing identity providers, changing data permissions or creating/editing policies within a Pod MUST be recorded using a well-defined shape.
examples: data-log; policy-log; identity-log; access-control-log
A UserRegistry MUST contain information regarding the DataSubjects storing data within a Pod, the PodAdmin and all other users, e.g., ReadUser, WriteUser or AdminUser, that might have access to the Data.
Users MAY be directly associated with a DataRequest so that they can make requests for data without using an application or service. These DataRequests should be checked for compliance to conformance with the ODRL profile for access control, e.g. example of a data request policy available in Section 3.4.
Users MAY have multiple UserAgents, which SHOULD be registered in the UserRegistry.
example: user-registry

Agent Conformance

For an Agent to be conformant with this specification, the following conditions should be satisfied:

Is it enough to associate Logs, e.g., AppLogs, ServiceLogs, DataLogs, etc., with the agents that generated them (in case there is an agent acting on behalf of something), or should it be defined one or more shapes, depending on the type of agent, for an AgentLog?

Agents activity MUST be in accordance with the manifest of the entity for which they are acting on behalf of.
A record of the usage of an AppAgent, ServiceAgent or UserAgent MUST be kept in the AppRegistry, ServiceRegistry or UserRegistry, respectively, including information regarding its providers/developers for accountability.
examples: app-registry; service-registry; user-registry

Workflows

In this section we define different scenarios and explain how the terms defined in PLASMA should be used, assuming that the entities and infrastructure used in the scenario are in conformance with the requirements specified in Section 4.

Provisioning a Pod

The provision of a Pod, and related infrastructure used to implement it, may have different setups depending on the actors that develop and provide the Pods, e.g., in a completely self-managed scenario, the User is the Entity responsible for the provision of the infrastructure, platform and software deployed for the usage of Pods, while in an opposite scenario, the User relies on Providers and/or Developers to implement and deploy all the infrastructure needed to use a Pod.

User needs to get an identity document through a IdentityProvider and keep a IdentityLog regarding the identity provision.
User needs to get a Pod through a PodProvider.
If the User grants authorisation to a UserAgent to act on their behalf, then a Log of the actions of the Agent must be kept.