Re: [w3ctag/design-reviews] TAG review for web app `scope_extensions` (Issue #875)

Thank you for the fresh review. 

Current test: 
`url.startsWith(origin + scope)`

New test: 
`url.startsWith(origin + scope) OR`
`url.startsWith(any origin in scope_extensions) OR`
`registrableDomain(url) == registrable domain in scope_extensions`

origin: This is the entire origin where there is no additional scoping filter.

registrable domain: replacing this with "site" and using the same-site test seems like a viable option. We still want to allow the developer to be able to provide a single origin association file at the manifest-provided site to validate the scope extension. 
@dmurph what do you think? 

### Scope filtering

Allowing one or both sides (app manifest and origin/site) to filter the scope using one or more kind of filtering syntax is definitely a good idea. 
"...each could leave it unspecified if that is their choice" is what we want to start with. This is restrictive for app devs initially but we believe it will unblock many developer scenarios and allow us to better understand developer needs and design requirements for filtering. 

I think scope suffix in the origin association file is the most suitable first filtering syntax to implement as developers are already
familiar with how this works and it is a fast test to perform. What do you think about specifying this even if it is not implemented initially or would be it better to leave it to future work?

There is a common problem with a.) filtering from both sides and calculating the intersection and b.) using URLPattern: performance when matching URLs and the ability to convert the filter to OS-specific filtering syntax. The latter is necessary for OS integration features like URL handling where the OS performs the URL filtering. Both a.) and b.) could lead to slower filtering due to their complexity. Both a.) and b.) could be difficult to convert to OS-specific filtering syntax. 

I still think specifying no filtering syntax or just suffix scope match initially is the best way forward until we do the work to study
the performance and OS compatibility of filtering syntax options (URLPattern, etc).

### Validation from origin/site configuration

The .well-known/web-app-origin-association file hosted by the participating site identifies individual apps by their app id (`web_app_identity` in the explainer example):
```JSON
{
  "web_apps": [{
    "web_app_identity": "https://example.com/"
  }, {
    "web_app_identity": "https://associated.site.com/"
  }]
}
```

Each object can be extended to apply different scope filtering for each app independently. 

### Type: Value

This isn't strictly necessary but makes parsing slightly more convenient as `type` is a required string field and the whole object can be skipped if `type` is not found or it is not a recognized type in this UA.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/875#issuecomment-2197527451
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/875/2197527451@github.com>