Re: Towards closing the remaining issues in the TPE specification

ISSUE-137 alternative text proposal:

> A service provider MUST identify, using the machine-readable format specified in this document,
> 1) that it is a service provider,
> 2) its own party,
> 3) the party it is providing service to, and
> 4) whether the party it is providing service to is a first party, third party, or service provider.




ISSUE-144 objection:

I do not believe the TPE protocol should constrain websites and users to a take-it-or-leave-it slate of privacy choices.  Users should be able to selectively grant a subset of requested exceptions.  A website may choose to respond by requiring the full set of objections.


ISSUE-164 alternative text proposal:
> If multiple domains on a page belong to the same party, then this fact MUST be declared using the same-party attribute. 
 



On Monday, October 1, 2012 at 9:23 AM, Matthias Schunter (Intel Corporation) wrote:

> Hi Folks,
> 
> I did a pass over the ISSUES that are still open (OPEN/PENDING REVIEW) 
> within the TPE spec. Enclosed is my suggested way forward for each of 
> them based on our WG discussions so far. Note that I did not include the 
> discussions that are RAISED. We will discuss a subset of those and agree 
> how to proceed with them.
> 
> Feedback is welcome. In particular if you do not agree with the proposed 
> handling of these issues.
> 
> Regards,
> matthias
> 
> --------------------------------8< ---------------------
> ISSUE-111: Using DNT header to signal existance of exceptions
> - currently not in spec
> - Spec allows JS Api to query exceptions
> - This allows sites to validate that their requirements are met
> - This seems to be OK for the participants
> - WAY FORWARD: Close issue unless objections are received
> 
> ISSUE-116: DOM API
> - There is proposed text in the spec in Section 4.3
> - This text seems undisputed
> - WAY FORWARD: Close issue unless objections are received
> 
> ISSUE-112: Handling of sub-domains for site-specific exceptions
> - Proposal 1: Explicit list no wildcards
> - WAY FORWARD: Discuss in Amsterdam
> 
> ISSUE-137: Service provider flag
> - We had discussions in two calls
> - Current spec does not contain a service provider flag
> - There seems to be no proposal without sustained objections
> - Call for text proposals has been emailed
> - WAY FORWARD:
> - If no alternative text is proposed, the issue will be closed
> - If alternative text is proposed, the chairs issue a call for 
> objections
> 
> ISSUE-144: Constraints on user agents
> - There is proposed text in the spec in Section 6:
> - The current spec introduces a notion of exceptions that are stored
> - The current spec mandates that sets of exceptions are treated as a 
> unit, i.e., if exceptions for third parties {a,b,c} have been requested 
> on a site,
> then {a,b,c } can only be removed as a whole
> - Note: This means that a user can,e.g., no longer express a 
> preference to allow {a,b} while disallowing {c}
> - This text seems undisputed
> - WAY FORWARD: Close issue unless objections are received
> 
> ISSUE-159: TPEs and mashups
> - Concern has been raised
> - No proposed solution yet
> - WAY FORWARD: Postpone for now
> 
> ISSUE-160: API for querying exceptions
> - The current spec contains a new querying API in section 6.6
> - WAY FORWARD: Close issue unless objections are received
> 
> ISSUE-164: Under what conditions should same-party be mandatory
> - Current spec declares the same-party attribute to be optional
> - WAY FORWARD:
> - If no alternative text is proposed, the issue will be closed
> - If alternative text is proposed, the chairs issue a call for 
> objections
> 
>