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

Those people who have been involved asked me to thank you for being responsive to feedback.  This is very much appreciated.

Some questions from just me, from looking at this with somewhat fresh eyes:

Scopes are a path prefix on the current origin.  This adds two types of scope extension: origin and registrable domain, but it is not clear to me what the concrete test is.  Presumably, when a navigation link is presented in the "app", the container needs to make a call about whether this is an "in-app" navigation or it is "leaving the app" (which might result in a warning or opening the URL in the "main browser").  Currently, the test is `url.startsWith(origin + scope)`.  This extends that to include some number of additional tests, but these are not immediately obvious.

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.)

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.)

Your future extensions mentions:

> More specific scoping e.g. scope suffix or include/exclude lists or [URL patterns](https://wicg.github.io/urlpattern/).

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).

@ylafon suggests URL patterns for this rather than path prefixes, though I'm personally less firm about that, because prefixes are easier to understand. The manifest has a path prefix in scope, which makes sense there, mostly because we didn't have URL patterns at the time.  A URL pattern is pretty reasonable if you think it is adequately comprehensible.

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.

That might lead to an authorization like this, for a hypothetical payment provider:

```json
{
  "web_apps": [
    {
      "manifest": "https://example.com/app/manifest.json",
      "scope": "/payments/*",
    }
  ]
}
```

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

```json
{
  "scope_extensions": [
    { "site": "example.com", "scope": "/*" },
    { "site": "foo.example", "scope": "/that_app/*" },
    { "origin": "https://bar.example.net", "scope": "/that_app/*" },
  ]
}
```

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

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