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.
PLASMA aims to provide a set of taxonomies to express Solid-related use-cases in terms of:
In addition to specifying a taxonomy of different types of policies, PLASMA promotes the usage of ODRL and DPV to determine access control to Solid Pod's resources and provides examples for using said policies.
PLASMA also provides the conditions for Pods, apps, services, users and agents to be conformant with this specification, as well as different workflows scenarios where the terms here defined are used, e.g., get a Pod, add data to a Pod, create policies or auditing apps. Finally, a legal compliance section was specified to describe how PLASMA terms can be related with data protection laws such as the GDPR and what is missing and needs to be considered.
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.
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.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.
Pod: A Personal Data Store or a 'Pod' that conforms to the Solid specifications.Agent: An actual or virtual entity associated with carrying out actions within or related to a Pod or its Data.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, 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 its association with Services and Apps.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. 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.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.
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> .
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 PodProvider also provides an identity credential for use with the Pod.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 developer would be the entity that created the certificate, while the PodProvider would be the provider for the identity.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.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.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.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.
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.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 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.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.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 succeffully 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 schemas for Data, 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.Currently, Solid has two specifications to determine access authorisations to resources in Solid Pods.
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.
In this example, User A issued a preference policyhttps://example.com/preference1that permitsoac:Readaccess operations over itsoac:Agedata for the purpose ofdpv:AcademicResearchif the legal basis isdpv:Consent.
<https://example.com/preference1> a oac:PreferencePolicy ;
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
]
]
] .
In this example, User A issued a requirement policyhttps://example.com/requirement1that permitsoac:Readaccess operations over itsoac:Identifierdata for the purpose ofdpv:IdentityVerificationif the legal basis isdpv:Consent.
<https://example.com/requirement1> a oac:RequirementPolicy ;
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
]
]
] .
In this example, User A issued anodrl:Offerwith the identifierhttps://example.com/offer1, based on the requirementhttps://example.com/requirement1and preferencehttps://example.com/preference1policies, as is indicated by thedct:sourceproperty. The permission associated with the requirement policy contains the propertydps:hasContextassociated with the termdpv:Requiredto indicate that said permission is a requirement, while the termdpv:Optionalis used to identify the rules related with a preference policy.
<https://example.com/offer1> a odrl:Offer ;
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
]
]
] .
In this example, User B issued anodrl:Requestwith the identifierhttps://example.com/request1tooac:Useoac:Agedata for the purpose of conducting an academic research project X.
<https://example.com/request1> a odrl:Request;
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 allowoac:Readaccess operations over User A'sAgedata for the purpose of academic research project X. Thisodrl:Agreementis the result of the matching ofhttps://example.com/offer1andhttps://example.com/request1, as indicated by thedct:referencesproperty. The legal basis of the agreement is consent, as is specified in the policy with thedpv:hasLegalBasis dpv:Consentterms, and User A and User B are registered as the data subject and data controller in question, respectively, using thedpv:hasDataSubjectanddpv:hasDataControllerterms.
<https://example.com/agreement1> a odrl:Agreement ;
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 ] ] .
In this example, User A and B reach an agreement to allowoac:Readaccess operations over User A'sContactdata for the purpose of academic research project X. Thisodrl:Agreementis the result of the matching ofhttps://example.com/offer2andhttps://example.com/request2, as indicated by thedct:referencesproperty. The legal basis of the agreement is a contract, as is specified in the policy with thedpv:hasLegalBasis dpv:Contractterms, and User A and User B are registered as the data subject and data controller in question, respectively, using thedpv:hasDataSubjectanddpv:hasDataControllerterms.
<https://example.com/agreement2> a odrl:Agreement ;
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.
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:
PodManagementDataAccessControlRegistryPolicyRegistryDataRegistryDataSchemaRegistryPodManagementData 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 by the Pod.AccessControlRegistry and PolicyRegistry, DataRegistry and DataSchemaRegistry.AccessControlRegistry.UserRegistry.For an App to be conformant with this specification, the following conditions should be satisfied:
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.
AppManifest needs to be developedAppRegistry.AppRegistry needs to be developedAppDeveloper 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.Apps MAY have multiple AppAgents, which SHOULD be registered in the AppRegistry.
ex:app a :App ;
:hasManifest ex:app-manifest .
ex:app-manifest a :AppManifest ;
dc:language "en" ;
dc:title "Super Racer 3000" ;
interop:applicationName "Super Racer 3000" ;
dc:description "A racer game app." ;
interop:applicationDescription "A racer game app." ;
…
odrl:hasPolicy ex:DataRequest ;
dpv:hasPolicy ex:appPrivacyPolicy .
For a Service to be conformant with this specification, the following conditions should be satisfied:
Services SHOULD have a ServiceManifest.ServiceManifest needs to be developedServiceRegistry.ServiceRegistry needs to be developedServiceDeveloper 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 app using dpv:hasPolicy either through internal triples or external links.Services MAY have multiple ServiceAgents, which SHOULD be registered in the ServiceRegistry.For a User to be conformant with this specification, the following conditions should be satisfied:
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.IdentityLogDataLogAccessControlLogPolicyLogSecurityLogUserRegistry 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.UserRegistryUsers 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.For an Agent to be conformant with this specification, the following conditions should be satisfied:
Agents activity MUST be in accordance with the manifest of the entity for which they are acting on behalf of.AppAgent, ServiceAgent or UserAgent MUST be kept in the AppRegistry, ServiceRegistry or UserRegistry, respectively, including information regarding its providers/developers for accountability.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.
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.User grants authorisation to a UserAgent to act on their behalf, then a Log of the actions of the Agent must be kept.Different scenarios whould be considered when adding Data to a Pod, i.e., data can be generated by the Users or other DataProviders or can be added by Apps, Services or Agents. In order to deal with these different scenarios, the following requirements should be taken into consideration:
DataLog when Data is added to the Pod, including information on the DataProvider.ResourceMetadata, e.g., resource A contains health data :resourceA dpv:hasPersonalData dpv-pd:Health.Users should add Policies to determine access to Data stored on their Pod.
Policies such as UserPreferences, UserRequirements and UserOffers to the Pod.PolicyLog when a Policy is added/updated to the Pod.An App request to use Pod Data is encoded as a DataRequest.
User needs to be authenticated and an IdentityLog regarding the identity verification should be kept.AppData, such as the AppMetadata, AppPersistentData, and AppTemporaryData, is stored in a AppLog.DataRequest from the AppManifest.DataRequest with the UserPreferences, UserRequirements and UserOffers.AccessControlLog of the DataRequest and DataAgreement.A Service request to use Pod Data is encoded as a DataRequest.
ServiceData, such as the ServiceMetadata, ServicePersistentData, and ServiceTemporaryData, is stored in a ServiceLog.DataRequest from the ServiceManifest.DataRequest with the UserPreferences, UserRequirements and UserOffers.AccessControlLog of the DataRequest and DataAgreement.In the specific case where processing operations over Data stored in Solid Pods are processed outside of the Solid platform, the User might want to have the results of said processing returned and stored in a specific container of their Pod.
DataLog with information on the Data being processed, where the processing is occuring and the technologies used.DataAgreement must contain information regarding where the generated data should be stored and whether a copy of the data can be kept outside of the Pod.External entities, e.g. data protection supervisory authorities, might need to have access to provenance data such as entities data, logs, policies, etc., kept in Solid Pods in order to procede with an auditing activity.
Logs of operations on data, identity verification and security incidents with information regarding the involved entities, operations on data and temporal information.Listing out how these terms relate to GDPR (and GDPR-like laws), what is missing, what needs to be done additionally.