search

privacycg / private-click-measurement

Private Click Measurement
https://privacycg.github.io/private-click-measurement/
196 stars 8 forks source link

Well-known url endpoint naming #59

Closed johnivdel closed 3 years ago

johnivdel commented 3 years ago

Given the discussions on #30 and #56, would make sense to update the URL endpoint naming to reflect the same principles? Namely, the other attributes have dropped the "ad" nomenclature.

For the Event-level Conversion Measurement API we are proposing using the following URL endpoints:

/.well-known/trigger-attribution for the path used to trigger attribution for a click.

/.well-known/report-attribution for the path where the report will be sent.

Currently, the same path is used for both triggering attribution and sending reports, /.well-known/ad-click-attribution. Assigning separate paths for these would make their usage/meaning more straightforward when being used across different context.

cc @johnwilander @csharrison

johnwilander commented 3 years ago

This currently sits as /.well-known/private-click-measurement in our implementation.

csharrison commented 3 years ago

/.well-known/trigger-attribution for the path used to trigger attribution for a click.

/.well-known/report-attribution for the path where the report will be sent.

This scheme looks good to me. @maudnals FYI

eligrey commented 3 years ago

.well-known URIs coexist with each other and the suggested endpoints seem somewhat vague at first glance.

A good compromise could be to put these both under a common .well-known path:

maudnals commented 3 years ago

If a common well-known path is chosen as @eligrey suggests, maybe we could land on a common path that is agnostic to the API name? Some ideas:

johnwilander commented 3 years ago

I've given this a great deal of thought since our last call and I want to go with scoped well-known locations. The reason is that there will be differences in how PCM and Conversion Measurement API work and we need to be able to design accordingly, without blocking each other from making progress. For instance, we are talking about third-party reporting endpoints stated in a well-known location (https://github.com/privacycg/private-click-measurement/issues/57) and we are talking about fetching fraud prevention tokens and signing certificates from a well-known location (https://github.com/privacycg/private-click-measurement/issues/27). This only introduces a scoping path element which an be replaced and the rest can be reused as best we can.

My preference is therefore:

… as proposed by @eligrey.

johnwilander commented 3 years ago

This has now been updated in the spec: https://github.com/privacycg/private-click-measurement/commit/f7e51bebbedc90419d6e39ea7cebb1d8ab687cc3