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

Hello!

A few thoughts:

@martinthomson said:
> origin: is this the ENTIRE origin? If you imagine an external service that provides a limited service, it might be preferable to specify a limited scope on that origin. (Obviously, you can't just use the scope specified in the manifest, because it won't make sense on a different origin.)

(later)

> Another nit, but the whole { type: "foo", value: "bar" } construction is a bit redundant, how about making this simpler?

AFAIK this has been the only request from our partners. I think it would be reasonable to add a 'scope' parameter to the 'origin' type, or a new type. I worry about using a "bag of parameters" here as it can lead to complications if more options are added & trying to figure out how they might combine. (AKA - what if you specify both origin & site? we would have to specify what this behavior means, and future options increase the cross-product complexity). It's clearer to have this format:

```json
"scope extensions": {
    { "type": "site", "value": "https://example.co.uk" },
    { "type": "origin", "value": "https://helpcenter.example-help-center.com" }
    { "type": "url_prefix", "value": "https://my_github_project.github.io/production/" }
}
```

(or - add a 'path_prefix' member for 'origin' types). Feel free to bikeshed "url_prefix". But this has not been a request from developers. If you feel strongly about needing this, that type is not complex to implement. Lu also mentioned better for cross-user-agent capabilities if this needs more - the functionality is based on the type, not based on arbitrary options.

@martinthomson said:
> registrable domain: I think that you want "site" here and want to use a [same-site test](https://html.spec.whatwg.org/multipage/browsers.html#same-site) for testing. This creates a broader match set that needs to be authorized on a per-origin basis, which is fine, but it has the same problem regarding scope on a per-origin basis. (Naming this "site" might be a better naming choice, with the value being a host rather than what appears to be an origin in the explainer. The scheme can be implicitly HTTPS.)

This sounds good to me - the important part is that we use the public suffixes list, which that algorithm uses through [obtaining the site](https://html.spec.whatwg.org/multipage/browsers.html#obtain-a-site).

@martinthomson 
> We tend to think that this is necessary - in two directions. That is, both the app and the new origin should be able to specify which resources are included, with the end result being the intersection of those sets (each could leave it unspecified if that is their choice).

As far as I know, this has definitely not been a request from partners. I worry this isn't necessary and increases the complexity of this feature. It also seems not necessary - the `web-app-origin-association` file is used to convey ownership / two way handshake of the site. With this established, the manifest is trusted to specify what it needs.

@martinthomson  said:
> Also, we observe that a single origin can include multiple apps with different manifests, but the authorization from the new site does not -- and cannot -- identify a single app. It's reasonable to say "I authorize any app", but it might be better to have it the authorization be scoped to specific apps, which might have different authorized scopes.

As Lu pointed out above, this is not the case. The web app identities are listed explicitly in the `web-app-origin-association` file.

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

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