Well-known url endpoint naming

[johnivdel]

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]

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

[csharrison]

/.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]

.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:

• /.well-known/private-click-measurement/trigger-attribution
• /.well-known/private-click-measurement/report-attribution

[maudnals]

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:

• /.well-known/attribution/trigger-attribution and /.well-known/attribution/report-attribution
• /.well-known/measurement/trigger-attribution and /.well-known/measurement/report-attribution // Maybe other/future measurement-related APIs could be nested under /measurement

[johnwilander]

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 (#57) and we are talking about fetching fraud prevention tokens and signing certificates from a well-known location (#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:

• /.well-known/private-click-measurement/trigger-attribution
• /.well-known/private-click-measurement/report-attribution

… as proposed by @eligrey.