Extension for IEEE P7012 (P7012)

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.

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

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 Creative Commons: About Licenses 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.

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.

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. We also recommend using existing relevant standards for representing and cataloguing terms and agreements, particularly the Data Catalog Vocabulary (DCAT), and using ODRL Information Model 2.2 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.

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.

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