What are the required fields for the TSR?

[rvaneijk]

We should talk about what is a valid representation of the TSR. The current spec states: "A status object MUST have a property named tracking with a string value containing the tracking status value". Other properties may be required for a TSR to be a valid one within the EU framework.

[royfielding]

An EU framework (or California Framework, Canadian framework, etc.) might indeed place a requirement on the existence of one or more additional properties in a TSR that claims compliance to that framework. However, that would be a framework requirement, not a TPE requirement, and is already anticipated by the current design.

[michael-oneill]

The TPE already has had a population explosion of Tracking Status Values, many inappropriate in different compliance regimes, and which we spent a lot of time discussing.
The TPE is our "technical document" which contains elements that can be referred to by compliance documents, and is the natural place to define at least some of these building blocks.

[royfielding]

We did define the building blocks. Those blocks can be required by the compliance regimes.

The fields required by TPE (the base protocol) are defined by the tracking status object: "tracking" is the only field always required. Some of the optional fields might also be required for certain tracking status values, as defined in the sections below that one.

[michael-oneill]

This is a comment to issue #21, which is also relevant here.

I think there should still be a requirement for a controller property, or some other way to identify the controller(s) of an origin, especially if the Exception is being requested by a subresource iframe.

Even if it is a visited first-party page, there may be no way find out the identity of the controller, the page might not refer to an about page or a privacy policy page.

So we should require the controller's identity to be explicitly declared in the TSR before an exception is granted.

[mschunte2]

There are multiple points to discuss:

• What attriutes of the TSR do we pre-define?
• Are compliance regimes allowed to add their own attributes?
• What subset is mandatory?
  • Currently: Tracking
• Under what conditions can the exception API be used?

[rvaneijk]

For the discussion that @mschunte2 staged:

I see a need for multiple policy attributes. For instance, reference to a resource's (a) cookie policy, (b) privacy statement, (c) security policy, e.g., a responsible disclosure policy, (d) terms and conditions, and (e) a DNT policy as required by AB370. There is no straight forward way to distinguish at the moment whereas for consent this information should be easily available. I propose to add metadata such that UI's can use these hooks when providing information to the user, when needed.

There are multiple ways of dealing with this need. I propose three alternatives:

A: extending the policy attribute to an array of strings. For example:

"policy": ["https://webresource.com/cookies", "https://webresource.com/privacy", "https://webresource.com/security", "https://webresource.com/terms_and_conditions"]

B: instead of having one policy property, extending to multiple policy properties. For example:

"cookies_policy": "https://webresource.com/cookies"
"privacy_policy": "https://webresource.com/privacy"
"security_policy": "https://webresource.com/security"
"terms_and_conditions": "https://webresource.com/terms_and_conditions"

C: extending the policy attribute to an array of key-values. For example:

"policy": [("cookie_policy", "https://webresource.com/cookies") , ("privacy_policy", "https://webresource.com/privacy"), ("responsible_disclosure_policy", "https://webresource.com/security"), ("terms_and_conditions", "https://webresource.com/terms_and_conditions")]

Option C is my preferred proposal, since the array of key/values is easy to extend.

[michael-oneill]

I also prefer option C, but valid JSON would be:

{
"policy": {
"cookie_policy": "https://webresource.com/cookies" ,
"privacy_policy": "https://webresource.com/privacy",
"responsible_disclosure_policy": "https://webresource.com/security",
"terms_and_conditions": "https://webresource.com/terms_and_conditions"
}
}

i.e. an object containing named string properties

N.B. You can check for valid JSON at this website http://jsonlint.com/, it works well but unfortunately it is down today.

[michael-oneill]

The controller identity should be machine readable, so user agents can display it in, for instance, tabular or list form in a UI. Only having an arbitrary URI is not enough for this, because user agents could not easily parse it to, say, extract a company name.
I propose a new array of objects "controllerDescription" where each object contains at least one defined named string "name", identifying the controller's name as a string.
It is an object (not just a string) so other fields could be added containing things like contact details, contact details of the DPO etc.
e.g.:
{ "controllerDescription": [

{
"name": " Company Inc.",
"address": "1, Main St.\nTown\nUK",
"email": "contact@company.com",
"DPO": {
"name": "John Smith",
"email": "privacy@company.com"
}
},
{ "name" : "other controller"
}]

here it is in the "orderly" form:
array { object { string name; // Legal name of the data controller
string address?; // postal address of head office of controller
string email?; // email address for main contact
string tel?: // main telephone number for controller
object {
name; // name of person primarily responsible for data protection issues
address; // postal address of this person
email; // contact email address of this person
tel: // contact telephone number of this person;
} DPO?; // details of primary Data Protection or Privacy Officer
}
} controllerDescription; // object identifying the data controller(s) responsible for this website;

[royfielding]

Please don't add enhancement requests as issue comments. They can be made separate issues.

In any case, the purpose of controller is to be a unique identifier that has legal binding to the controlling party, which is best done with a registered domain. That's why the origin server's domain serves as the default. More information can be provided if a URI is supplied.

[mschunte2]

We did not agree to change the requiredness for any fields. This issue can be closed for now (The discussion of new fields is ongoing at this point and for those fields, the question remains open).