User Ids and Preferences to include Model Terms version information #179
Description
The specification concerning security and signatures includes an as yet undefined field for the protocol version. This problem has been discussed in the Policy group and recognized as an issue to be solved to enable multiple versions of the Model Terms to exist at the same time. It is simply not practical to require all participants to upgrade their contracts as precisely the same time.
This is currently being set to 0.1 for the Identifiers and Preferences in the MVP.
The Model Terms will change over time. There have already been 2 versions and there will likely be others in the future. The design must separate the protocol version from the Model Terms version.
There are two potential options.
HTML with Canonical links
To provide the greatest flexibility the specification for Preferences and Identifiers should change to include a field called "terms_url" which provides a URL that must return an HTML format document containing the Model Terms that were used when the preferences were captured or the identifiers generated.
The HTML specification supports the canonical link type following RFC 6596 which can be used to relate multiple URLs to the same Model Terms version.
For example; the URL https://prebid.org/paf/model-terms-v1-1.html could be the main version of the Model Terms version 1.1. Another web site might host the model terms at the URL https://another-site.com/model-terms-v1_1.html and include the following HTML element.
<link rel="canonical" href="https://prebid.org/paf/model-terms-v1-1.html" />Users of the preferences and identifiers would maintain a local cache of URLs and their canonical variants which would enable them to identify different URLs as the same Model Terms. Where their contracts which incorporate the Model Terms as standard contractual clauses with other receivers reference specific Model Terms via URLs they can refer to the list of related URLs to find a match.
An explanation of canonical URLs for developers is provided by Google for SEO and user friendly URL purposes here.
- Con: This approach increases the number of bytes required by the Preferences and Identifiers data structures. However as the approach is to use JSON with compression the overall impact on the compressed number of bytes is likely to be minimal. There are also likely to be a relatively small number of URLs in practice and the URL lengths can be encouraged to be as short as possible. i.e. "https://network.org/mt1-1" rather than "https://network.org/model-terms-v-1-1.html". These approaches combined provides some mitigation.
- Pro: Complete flexibility concerning the number of Model Terms maintainers and the URLs for the Model Terms. If Model Terms were to follow the same path as open source licenses then they will diverge and merge over time as the GNU Public License became the Lesser Public License.
Terms version with mapping
A central relationship between versions and Model Terms URLs could be maintained by a single Model Terms maintainer. This would follow the existing protocol version approach where a version value related to a URL. The following table could be published in the repository that controls the Model Terms documents.
| Version String | Model Terms URL |
|---|---|
| 1.1 | https://prebid.org/paf/model-terms-v1-1.html |
| 1.2 | https://prebid.org/paf/model-terms-v1-2.html |
| 2.0 | https://prebid.org/onekey/mt2.html |
- Con: This would reduce flexibility as there would need to be a central maintainer of all Model Terms and others would likely need to fork the specification to incorporate alternative Model Terms. This might be attractive to a publisher that wished to use the specification and source code across their own brands only and use their own terms. Of course this ignores the commercial reality that such a deployment is unlikely to be attractive to advertisers that value the common Model Terms, preferences, and widely used identifiers.
- Pro: The number of bytes needed to communicate the Model Terms version and document would be reduced.
Other approaches
There may be other approaches that should be added to the issue comments.
Suggested next step
The Architecture and Policy groups need to agree a solution before a Pull Request is made to modify the security and signatures specification to include the amendments.
The different approaches could easily be compared for efficiency within the MVP project full data structures to determine the overall number of bytes needed to support the two approaches. Once that research is done then the Architecture group can make a recommendation to the Policy group.