Domain association file is unable to grant permission and control URL handling for individual sub-domain origins.

[LuHuangMSFT]

url_handlers entries are allowed to specify origin strings with a prefix wildcard pattern so as to include one or more sub-domains. The use of this pattern could cause one or more origins to be included.

If there is still only one association file that can be found and downloaded based on the origin pattern, this could lead to a single association file being used to grant permission and control paths for more than one origin.

Is the current assoc. file format suitable for this scenario?

Look at the example below. Assume it is hosted at https://service.com/web-app-site-association.json. Assume the manifest at https://contoso.com/manifest.json has a url_handlers entry for a `*.service.com" origin pattern.

{
    "web_apps": [
        {
            "manifest": "https://contoso.com/manifest.json",
            "details": {
                "paths": [
                    "/*"
                ],
                "exclude_paths": [
                    "/blog",
                    "/about"
                ]
            }
        },
        {
            "manifest": "https://partnerapp.com/manifest.json",
            "details": {
                "paths": [
                    "/public/data/*"
                ]
            }
        }
    ]
}

The first main entry specifies paths and exclude_paths to the `https://contoso.com/manifest.json" app. But which origin do the paths and exclude paths refer to? The only valid answer currently is "all and any that fits the pattern."

This is useful for an app at say "https://portal.com/manifest.json" to enable URL handling of "https://org1.portal.com/" URLs and "https://org2.portal.com/" URLs. In this situation, sub-domains could be used by tenants for vanity or branding purposes, but does not cause any differentiation in path structure (i.e. sub-domain origins are homogeneous). A "/files/*" in the paths member would work equally well for all tenants.

The association file is unable to grant permission and control URL handling for some but not all sub-domain origins. If there is a reasonably number of heterogeneous sub-domains that need control, the manifest should add each explicitly (eg. blog.content.com, music.content.com, chat.content.com, etc.) Each can associate with a separate association file.

Imagine a WYSIWYG web host and website builder like wix.com. If it wishes to allow all of the heterogeneous websites with different sub-domains (eg. cats.wix.com, dogs.wix.com) to associate with a PWA, it could allow /* in paths, but would not have much control beyond that. If it wishes to enable URL handling for some but not all sub-domains without updating the manifest, it is unable to specify so with the current format.

Extensibility

The scenarios described above were decided to not be requirements for the current design so the format can remain easy to use and address the most common cases. To address them in the future and still remain backwards compatible with the current format, there are some ideas that could be considered:

• Adding a format version number to the main object. If this is found, web_apps could be parsed differently.
• Reading multiple association files. Instead of 1 association file for many sub-domain origins, the UA could look for and download many association files at the same location. This could also be done with a <link rel> entries in the document, similar to how manifest is found.
• The spec. could be amended such that the UA can optionally look for an index of association files.
  None of these solutions seem ideal but they could be investigated if the need arises.