[VK Company Feedback] Domain lists and signers

[NekR]

Hello!

We're trying to understand how exactly Signed assertions would work and how we should prepare to it.
From the docs in this repository it isn't 100% obvious if Signed assertions would be used at all. Reviewing this repo ~6 months ago, we saw it used mostly "signer" terminology. Now it says that browsers should either have static list of FPS deployed to them or use external signer entity. What is current decision on forming FPS lists?

Browsers should maintain a static list of site-declared groups of domains which meet UA (User Agent) policy, and ship it in the browser as a reliably updateable component
...
Sets will expire after a prescribed period of time, and be required to undergo renewal. This prevents sets from becoming stale, in case domain ownership changes.

Would this behavior require any actions from the services (websites) to renew their sets?

The signer then regularly produces fresh signed assertions for the current list state.
...
Assertion lifetimes should be kept short, say two weeks
...
To avoid operational challenges for sites, the signer makes the latest assertions available at a well-known location, such as https://fps-signer.example/assertions/

From this, signer seems like another point of failure for the services. It can be down; it may become not available in a country; it may withdraw a certificate randomly; etc.
This sounds like an issue for the businesses in comparison with current situation where third-party cookie provide 100% uptime for cross-browser requests.
Also there already are questions about legal side of such third-part entity: #64

Thanks.

[krgovind]

@NekR - You are correct that in one of the original drafts of this proposal, we did have use a signed assertions-based design. However, we have since updated the proposal to prefer a static list-based approach. The previous design is still documented as an alternative solution that we may reconsider in the future, should we find that the static list doesn't scale well. The signed assertions design can indeed be further defined to address your questions, but we are currently prioritizing the static list approach.

To learn more about the proposal for the current static-list-based design, please see this section and also this document to understand how a first-party set formation request from a site author comes to be included in the static list consumed by browsers.

To your questions on the alternative design:

Would this behavior require any actions from the services (websites) to renew their sets?

This is currently not defined (it could happen automatically, or require action depending on the verification process); but will certainly be defined, should we implement the signed assertions approach.

From this, signer seems like another point of failure for the services. It can be down; it may become not available in a country; it may withdraw a certificate randomly; etc.

Thank you for the feedback. I think we could potentially tune some of aspects of the process to address these (e.g. slightly longer expiry with the ability to secure renewals in advance, multiple signature providers, etc.). I don't believe the same concerns translate to the static-list-based approach, but please do call them out if you think they do.

Also there already are questions about legal side of such third-part entity: #64

We are in the process of iterating on the UA policy, and enforcement process; and we will certainly consider this challenge as we do that.

[NekR]

That makes sense, thank you!

To learn more about the proposal for the current static-list-based design, please see this section and also this document to understand how a first-party set formation request from a site author comes to be included in the static list consumed by browsers.

Re-reading the docs, I think I have a few more questions. What is expected time in which browsers would be updating their lists after something is added to it?

In the docs I see this requirements for FPS owners and I believe similar requirement should be made for browsers, so that FPS lists are always updated in predictable time-frame:

This means that changes in ownership/controllership must be followed up with a request for changes in the site's First-Party Set within XX [to be determined] days.

---

I'm thinking about some possible "new products launch situations" where static lists may get into the way. For example, imagine Google is about to launch Google Wave+ service which they want to host on gwave.com, but they want it to be a surprise and a big launch. Or maybe YouTube is being renamed to Mega and they want to migrate to Mega.com. But at the same time, these products still should have access to seamless authentication (and other features of FPS) on new domains. So Google would need to submit information about their new products to public list and share such information before public launch.
What are your thoughts and plans here?

---

In the docs about static lists, I see mentions of "Responsibilities of Independent Enforcement Entity" which sounds like browsers won't be those entities which hold and operate on the static lists. How would this work exactly and how could it affect timing of static list deployments?