Parties

In [[IEEE-P7012]], parties are defined with a specific role in the context of a contract. [=Person=] as the human individual is always the 'First Party', the [=Entity=] which is always an Organisation is always the 'Second Party', and any other party is always a 'Third Party'.

[[IEEE-P7012]] requires and relies on [=Agent=] (as in software or machine agents) to express preferences, make decisions, and enter into contracts. To distinguish between agents acting on behalf of parties, a [=PersonAgent=] represents the [=Person=] and an [=EntityAgent=] represents the [=Entity=] organisation.

Processes

The following concepts represent the activities and artefacts involved in the process:

Model

To provide the person (and by extension - organisations) a simple way to select and express terms, the following set of agreements have been developed based on the [[[CC-ABOUT]]] model where a baseline term is defined and further terms are added to have the intended effect. Such as the baseline term in the CC model (called CC-BY) represents the requirement to acknowledge authorship and provides a broad permission to other activities with the resource, which is then restricted through additional terms and represented by extending the acronym (see [[CC-CHOOSE]]). To adapt this to P7012, the baseline term must represent the key reason why the term is needed - which is the intention to receive a 'service'. However, unlike CC-BY, the person is not signalling that the service provider or any (random) third party can do whatever else they want - such as the commonly required but misused activities of analytics, tracking, profiling, or data sharing.

Based on the above, the following terms have been developed and formulated as acronyms which can be easily understood in combinations:

• Service Delivery (SD)
• Data Portability (DP)
• Analytics by Second-Party (A)
• Analytics and Tracking by Second-Party (AT)
• Analytics, Tracking, and Profiling by Second-Party (ATP)
• Share Anonymised Data with Third Party (S3P)
• Personal Data Contribution (PDC), i.e., proactive contribution of data by a person towards some specific objective/purpose
• Intent Casting (INTENT)
• AI Training and Operation (AI)
• Public Good (GOOD)

The development of the terms consider what activities are commonly required by organisations, whether as part of providing a service, or tangential to it. In this, the activities of analytics, tracking, and profiling were found to be desirable when conducted by an organisation providing the service - such as to understand the usage of the service, evaluate performance and response times, and to understand users. However, these same activities were found to be problematic and a widespread issue when conducted by - often unauthorised - third parties. Therefore, the use of these terms in combinations is about expressing how the organisation acting as the second party can or cannot perform these activities, while third parties - who often have no relation to the individual nor do they provide any benefits - are always prohibited.

Defined Agreements

The combination of these terms follows a naming model where the terms acknowledged within the acronym expresses what the second party, i.e., the entity organisation can do, and which any third party is prohibited to do. If the term is absent, it means it must not be done, i.e., it is prohibited for both the second and third party. Thus, the baseline term of [=SD-BY=] offers the 'highest privacy level' as it prohibits most activities, while the term [=SD-BY-ATP-S3P=] offers the 'lowest privacy level' as it permits most activities - however, it is imperative to note that even at this 'lowest' level, it is only the second party, i.e., entity organisation which is allowed to perform these activities. Thus, even at the 'lowest' level, the privacy level is still higher than the current norms as third parties are expressly prohibited from being involved in these activities.

In addition to whether activities may or may not be performed, the term DP represents an obligation to perform 'data portability', i.e., provide involved data back to the individual. This term is optionally added to other terms, and thus represents variations of those agreements. The intention of this term is to ensure that there is no vendor lock-in, and that the data of the individual is provided back to them. The Section on Terms expresses further developed concepts which have not been defined in acronyms, but which can be involved in agreements to express specific requirements such as regarding transparency, and to support the consistent interpretation of these terms across jurisdictions.

Summarising the above, the below table represents a visual overview of the provided agreements and how they permit or prohibit specific terms. In the table, the symbol '✓' means the term is permitted, i.e., it MAY BE optionally done, 'X' means the term is prohibited, i.e., it MUST NOT be done, and '○' means the term is an obligation, i.e., it MUST be done.

Defined Terms

While the agreement concepts provide a set of useful concepts to represent entire agreements, their interpretation requires that the agent or system knows about the intended meaning associated with the concept. This requires that each concept be individual coded in to the system, e.g., as a set of permissions, prohibitions, and obligations. To simplify and support this process, and provide a 'machine-readable' representation of what specifics each agreement entails, the following concepts represent the granular components which when combined can create the intended meaning as used in the agreement concepts.

Each concept is represented as a ContractualClause to reflect its use as terms involved in a larger agreement. To support the expression of what the clause contains, [[DPV]] Rule concepts are used to represent what the clause models, and are associated with the agreement concepts through contextual relations - hasPermission , hasProhibition , and hasObligation . Through this, the agreement is defined as a set of clauses or terms representing specific permissions, prohibitions, and obligations.

To further support implementations and human-oriented reviewing and other activities, the two relations [=hasMachineReadableFormat=] and [=hasHumanReadableFormat=] are provided. Using these, the agreement concepts can have different 'formats' and 'serialisations' to support implementing these in different systems. To express metadata about these, we recommend using [[DCTERMS]], such as `dct:format` and `dct:conformsTo` for machine-readable representations, and `dct:language` for human-readable representations.

To specifically describe the use of terms to humans, the property [=hasHumanDescription=] is provided. For example, the [=PortabilityTerm=] has the following text as a description for the use of that term in UI/UX:

"Data portability means that you are entitled to ask organisations that hold records about you (your personal data) to be sent in a modern, useful format either to you directly, or to another organisation/ app that you nominate. Examples of that might be your bank transactions (via Open Banking or similar), your home energy use, your vehicle use and many more."

We also recommend using existing relevant standards for representing and cataloguing terms and agreements, particularly the [[[DCAT]]], and using [[[ODRL-MODEL]]] for a standardised structure and interpretation of the terms and to represent and record interactions as 'offers', 'requests', and 'agreements'.

The terms defined and used to model the agreements are as follows:

• [=TrackingTerm=] for whether tracking is allowed or not, and associated using [=hasTrackingTerm=];
• [=ProfilingTerm=] for whether profiling is allowed or not and associated using [=hasProfilingTerm=];
• [=DataSharingTerm=] for whether data sharing is allowed or not, and associated using [=hasDataSharingTerm=];
• [=PortabilityTerm=] for whether a reciprocal data portability obligation exists to provide a copy of involved data, which is associated using [=hasPortabilityTerm=].

In addition to these, the following terms are provided to support further expression of relevant terms given common requirements or to address common issues, and to support the consistent interpretation and execution of terms:

• [=TransparencyTerm=] representing a reciprocal obligation to provide information, with further specific concepts for purposes ([=PurposeTransparencyTerm=]), parties ([=PartyTransparencyTerm=]), and data ([=DataTransparencyTerm=]), which are associated using [=hasTransparencyTerm=];
• [=DeonticInterpretationTerm=] for how the terms should be interpreted when there is no specific permission or prohibition covering an activity; which is associated using [=hasDeonticInterpretation=];
• [=ConflictResolutionTerm=] for how conflicts between permissions, prohibitions, and obligations should be handled, which is associated using [=hasConflictResolution=];
• [=AgentBehaviour=] for how agents should behave regarding requests ([=AgentRequestBehaviour=]) and regarding negotiations ([=AgentNegotiationBehaviour=]), which is associated using [=hasAgentBehaviour=];
• [=PreferenceApplicability=] for expressing when a privacy preference should be applicable, which is associated using [=hasPreferenceApplicability=].

Data

The following are specific data categories required in the expression of [[IEEE-P7012]] style agreements. It is associated using dpv:hasData or dpv:hasPersonalData relations.

Purposes

The following are specific purpose categories required in the expression of [[IEEE-P7012]] style agreements. It is associated using dpv:hasPurpose relation.

Expressing Privacy Terms using DPV

Expressing Privacy Terms using ODRL

Record showing full contract interaction

Simple Discovery and Negotiation

1. ServiceProvider queries PrivacyEndpoint of PrivacyAgent to start the privacy negotiation process by using p7012:PrivacyNegotiationRequested
2. PrivacyAgent responds to ServiceProvider that it agrees to negotiate by using p7012:PrivacyNegotiationInitiated
3. ServiceProvider requests PrivacyAgent to share its p7012:PrivacyPreference
4. PrivacyAgent informs ServiceProvider it will accept p7012:SD-BY-ATP-DP
5. ServiceProvider queries the PrivacyTermRegistry to retrieve p7012:SD-BY-ATP-DP and analyses whether it is acceptable for it or not
6. ServiceProvider informs PrivacyAgent that the PrivacyTerm is acceptable by using p7012:PrivacyTermsAccepted
7. PrivacyAgent sends a dpv:StandardFormContract to the ServiceAgent based on the selected PrivacyTerm
8. ServiceProvider accepts/signs the contract and sends it to the PrivacyAgent with status dpv:ContractUnderNegotiation (as all parties have not signed it yet)
9. PrivacyAgent accepts/signs the contract and sends it to the ServiceProvider with status dpv:ContractAccepted (indicating all parties have signed it)

Discovery and Negotiation with CounterOffer

1. ServiceProvider queries PrivacyEndpoint of PrivacyAgent to start the privacy negotiation process by using p7012:PrivacyNegotiationRequested
2. PrivacyAgent responds to ServiceProvider that it agrees to negotiate by using p7012:PrivacyNegotiationInitiated
3. ServiceProvider requests PrivacyAgent to share its p7012:PrivacyPreference
4. PrivacyAgent informs ServiceProvider it will accept p7012:SD-BY-ATP-DP
5. ServiceProvider informs PrivacyAgent it will not accept p7012:SD-BY-ATP-DP but will accept p7012:SD-BY-ATP by using p7012:PrivacyNegotiationCounterOfferMade
6. PrivacyAgent queries the PrivacyTermRegistry to retrieve p7012:SD-BY-ATP and analyses whether it is acceptable for it or not
7. PrivacyAgent informs ServiceProvider that the PrivacyTerm is acceptable by using p7012:PrivacyTermsAccepted
8. PrivacyAgent sends a dpv:StandardFormContract to the ServiceAgent based on the selected PrivacyTerm
9. ServiceProvider accepts/signs the contract and sends it to the PrivacyAgent with status dpv:ContractUnderNegotiation (as all parties have not signed it yet)
10. PrivacyAgent accepts/signs the contract and sends it to the ServiceProvider with status dpv:ContractAccepted (indicating all parties have signed it)

Using Contextual Privacy Preference

Always express this preference using p7012:PrivacyPreferenceAlwaysApplies and conditionally express using p7012:PrivacyPreferenceConditionallyApplies. Conditional means there is a 'context' that represents the condition, expressed using 'dpv:hasContext' and some 'dpv:Context'. For example,

1. Based on type of organisation, e.g. for non-profit (dpv:NonProfitOrganisation), the PrivacyTerm expressed is p7012:PDC-AI and p7012:PDC-GOOD
2. Based on location of the individual, e.g. if they are at work (loc:AtWork), the Privacy Term expressed is p7012:SD-BY
3. Based on age of the individual, e.g. if they are a child (dpv:Child), the Privacy Term expressed is p7012:SD-BY

Using Privacy Terms and Modifiers

p7012:SD-BY a p7012:PrivacyTerm ;
    dpv:hasPurpose p7012:ServiceDelivery ;
    p7012:hasPrivacyInterpretationModifier p7012:ProhibitiveInterpretation ;
    p7012:hasConflictResolutionModifier p7012:ResolvePreferringProhibition,
          p7012:ResolveOnlyWithinContext ;
    p7012:TrackingModifier p7012:TrackingDisallowed ;
    p7012:hasProfilingModifier p7012:ProfilingDisallowed ;
    p7012:hasDataSharingModifier p7012:DataSharingDisallowed ;
    p7012:hasPortabilityModifier p7012:PortabilityNotRequired ;
    rdfs:comment "lorem ipsum"@en .

Using PrivacyModifier in a PrivacyTerm, we can also express actions to be taken after the contract process has completed. In the below example, presuming this ia privacy term that is being used for a research organisation like a hospital to use data for research where purposes and parties may not be known ahead of time, the modifiers state that the purposes and data being created and used till that point should be communicated upon request, and that parties involved should be communicated or declared after the processing starts.

ex:Example a p7012:PrivacyTerm ;
    p7012:hasPurposeTransparencyModifier p7012:PurposeTransparencyOnRequest ;
    p7012:hasPartyTransparencyModifier p7012:PartyTransparencyExPost ;
    p7012:hasDataTransparencyModifier p7012:DataTransparencyOnRequest .

Classes