Eddystone->Web Bluetooth upgrade and Allowed Services

We're looking into
https://github.com/WebBluetoothCG/web-bluetooth/issues/163, to allow a page
opened from a Physical Web notification, to communicate with the device
that advertised its URL. There's a question around how to infer the Allowed
Services List (
https://webbluetoothcg.github.io/web-bluetooth/#allowed-services-list) for
such a device.

The Allowed Services List exists so that in the future we can build a
registry of UUID -> human-readable meaning, and then we can have the
requestDevice() dialog explain to users what exactly the website wants to
do with the device. For example, instead of "pair with", we might be able
to say "read your heart rate". In order to have that option in the future,
we have to enforce that developers accurately list their UUIDs today.

The Physical Web flow works approximately as follows (
https://github.com/google/physical-web/blob/master/documentation/technical_overview.md
):

   1. The browser receives a BLE advertisement including a URL.
   2. It sends this URL to a web service, which fetches the URL, scrapes
   metadata out of it, and replies to the browser with that metadata.
   3. The user is shown a list of URLs with titles, etc. and selects one.
   4. The browser opens that URL.
   5. The site uses Web Bluetooth to start communicating with the device.

I see 4 options for handling the allowed services list in the physical web
upgrade flow:

   1. Have the physical web service scrape the allowed services list out of
   the site and pass it to the browser. This allows the list of URLs in step 3
   to include the requested services.
   2. Have the site call a function to request additional services between
   steps 4 and 5. This would need to be in response to a user gesture and
   return a promise so the browser could show the user the requested services.
   This function would be useful in other situations too.
   3. Assume that if a device advertises a particular URL, then the device
   is designed to work with that site, and the user doesn't need to see the
   requested services. Other sites would still need to declare the services
   they're going to use.
   4. Give up on the allowed services list for all sites. (I don't think we
   should do this, but it's an option.)

Do the folks on this list have any opinions on which option we should pick?

Thanks,
Jeffrey