Operator Identity

This document is a member submission following discussions within the Tracking Protection Working Group and does not constitute working group consensus. Text in option boxes (highlighted with light blue background color) present options that the group is currently considering, particularly where consensus is known to be lacking, and should be read as a set of proposals rather than as limitations on the potential outcome. An issue tracking system is available for recording raised, open, pending review, closed, and postponed issues regarding this document.

Terminology

Notational Conventions

Introduction

This section is not normative.

Work in the TPWG (Tracking Protection Working Group) has identified a requirement for a way that the Do Not Track consent signal, otherwise known as the User Granted Exception (UGE), can be set or examined by client-side script for Origins other than the effective script origin. In order to not weaken security, or create another vector enabling device fingerprinting, this should be restricted to other Origins belonging to, or those managed by recognised service providers of, the administrator of the current page. Common use-cases are:

• An organisation manages many similar sites, such as different brand sites owned by a single consumer product company. If consent is obtained for tracking on one site it should not be necessary for solely technical reasons to repeatedly ask for consent when the user visits other brand sites. There may be reasons to repeat consent requests for different styles of sites, i.e. a user may agree to be tracked on food product sites but not on medical product ones, but this should be a function of the explanation given in text on the page and not arbitrarily limited by the constraints due to the implementation of the Same Origin Policy. If users are needlessly bombarded with consent requests they could find this irriating, avoid using the requesting application.

• Often a single website is implemented using resources on multiple Origins. Some resources may be addressed via the https protocol, others by http. At other times the resources may be addressed via different subdomains or entirely different domains, or on different Top Level Domains. It should not be required that consent has to established via script loaded, say using an iframe tag, in each of these Origins. In order to avoid repeatedly asking the user for consent complex cross-origin signaling mechanisms would have to be implemented.

• A publisher may wish to show contextual or consensual behavioral advertising while respecting DNT, but retain the ability to retarget those users later on other sites via a third-party service provider. The publisher should be able to request explicit consent from a user for this activity and then be capable of enabling a DNT UGE for the Origins of specially contracted service providers, in a granular fashion.

• An advertising exchange may initiate a bidding process for particular audience categories of users in a server-server transaction. The downstream bidders in this case are not accessed by HTML content on the page so cannot directly determine their own DNT consent status. The ad exchange should be able to contract itself as a service provider to the host page administrator as well as to the downstream bidders, and ascertain itself their DNT consent status. It can then efficiently build this information into the bidding process without having to disregard DNT by broadcasting the PII of DNT users.

Similar use-cases can be imagined for other APIs which convey or request client settings, such as the forthcoming Permission API. If a company asks a user for permission to receive, say, geolocation data it should not be necessary for simple technical reasons for this to be limited to a single Origin. It should be possible, with user agreement, to examine the Permission settings of particular service providers, or apply settings to other Origins used by the application.

When client-side script requests a change to an important setting, such as the Do Not Track web-wide exception setting, it should be possible to check the identity of the party responsible for the script. Simply reporting the host domain of the effective script origin could be inadequate in many situations. This document defines a declaritive mechanism so that the Operator, or the organisation, company or individual responsible for a web resource, can declare itself, and be associated with the current effective script Origin.

The Same Origin Policy is an important aspect of the web application security model. In order to retain this security the relationships between Origins need to be specified securely in an open and transparent, and therefore declarative way. When an API (i.e. DNT UGE) supports this kind of cross-origin setting or confirmation only Origins that refer to each other should be allowed to take part.

This document defines Operator Identity (SI), a mechanism that web applications can use to deliver a machine and human readable description of the website server administrator, i.e. the person, company or organisation legally responsible for website operation. An Operator Identity Descriptor is a declarative description that informs clients of properties that identify the website Operator, and optionally properties indicating other host origins it manages, the host origins of service providers it has contracted with, and the host origins of resources where it acts as a service-provider. .

In responses to clients a web application resource supplies an Operator Identity Descriptor in an HTTP header, or as the content of an HTML <meta> element in an HTML response body. This Operator Identity Descriptor describes the administrator of the current resource representation only. To supply an Operator Identity for an entire site, the server needs to supply a descriptor with each resource representation.

Only the first indication of an Operator Identity is valid. Subsequent versions in further response headers or meta tags are ignored.

On detection of an Operator Identity Descriptor a client will immediately parse it to create an OperatorID JSON object which includes all the properties defined in it. This object is referenced by the document.OperatorID property. Once an OperatorID object has been defined, any subsequent Operator Identity Descriptors are ignored. An internal representation of the OperatorID is cached so it is immediately available when this resource is referred to by a suporting API.

        Operator-Identity: name Publisher Inc.;
                uses https://advertise.com https://search.com;
                controls https://daily-record.ie https://thebeano.co.uk;

Syntax and Algorithms

            "Operator-Identity:" 1#operator-token
            

                        <meta http-equiv="Operator-Identity" content="name Publisher Inc.;
                                  uses https://advertise.com https://search.com;
                                  controls https://daily-record.ie https://thebeano.co.uk">

            operator-token   = [ property-token *( ";" [ property-token ] ) ]
            property-token = *WSP [ property-name [ WSP property-value ] ]
            property-name  = 1*( ALPHA / DIGIT / "-" 
            property-value = *( WSP / <VCHAR except ";" and ","> )
            

resource-list = *WSP [ source-expression *( 1*WSP source-expression ) *WSP ]
resource-expression = scheme-origin / host-origin 
scheme-origin = scheme-part ":"
host-origin = [ scheme-part "://" ] host-part [ port-part ] [ path-part ]
scheme-part = <scheme production from RFC 3986, section 3.1>
host-part = "*" / [ "*." ] 1*host-char *( "." 1*host-char )
host-char = ALPHA / DIGIT / "-"
port-part = ":" ( 1*DIGIT / "*" )
path-part = <path production from RFC 3986, section 3.3>

Properties

Processing Model.

An client-side API can support cross-origin communication by defining a parameter or an object property identifying other Origins. This API can then use the OperatorID object to determine if the other Origins referred to have properly formatted Operator Identities of their own, and that they refer to the Origin representing the effective script origin of the document that called the API.

If the current document does not have a defined OperatorID, processing terminates and the access to the other Origin disallowed. Otherwise, the current OperatorID is examined to check that the specified other Origins are referred to in the uses or controls Other Origin Resource List.

The OperatorID of each specified other Origin is obtained, either from a local cache or by requesting the resource with an HTTP OPTIONS method. The returned Operator Identity Descriptor is parsed to create an OperatorID object for the resource, which should be cached.

If the specified other Origin is referred to on a uses list, the other OperatorID is checked for a referral to a resource in a services list with an Origin equivalent to the current effective script origin. If there is no such back-referral, processing terminates and the access to the other Origin disallowed.

If a specified other Origin is on a controls list, the other OperatorID is checked for a referral to a resource in its own controls list with the Origin as the current effective script origin. If there is no such back-referral, processing terminates and the access to the other Origin disallowed, otherwise access is allowed.

Different access rights can be given to APIs according to whether they refer to service-provider Origins or other Operator managed websites. For example the TPWG TPE ConfirmWebWideTrackingException could allow script to read the DNT status of a site's service providers ( i.e. the Origins specified by the uses property ), while the StoreWebWideTrackingException would only allow granting of exceptions for Origins on the controls list, i.e. they represented resources controlled by the same Operator.