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

> Starting with a scope suffix per site/origin object (in the web-app-origin-association file) if this is sufficient to address concerns. Applying a scope to multiple origins that pass the same-site test places restrictions on the developer as the scope needs to make sense for all origins that pass the same-site test with their desired site.

I wasn't suggesting that the app manifest specify a scope.  That is, you would still just say `{"site": "service.provider.example"}` in the manifest of the app that is trying to extend the app scope to the service provider origin.  As you say, if you said `{"site": "service.provider.example", "scope": "/foo"}`, you are forcing multiple origins to all have the same structure.  Then, though "app1.service.provider.example" might have "https://app1.service.provider.example/foo", "app2.service.provider.example" either has to accept the same conditions on the use of that scope or not use "/foo", which is bad either way.

But that is the app provider imposing its will on the service providers, which is basically an RFC 8820 violation.  You want the service provider to speak for itself.

Instead, the opt-in from the service provider would list the apps that are authorized for use, plus a scope.  That is naturally origin-scoped anyway.  `{"web_apps": [{"web_app_identity": "https://example.com/", "scope": "/foo"}]}`, coming from "https://app1.service.provider.example/" would have the desired effect.  And then "app1.service.provider.example" can make its own choice about what to include (or not), which will be nothing by default.

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

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