Consider aligning with W3C MiniApp Manifest

[tomayac]

The W3C MiniApp Manifest spec is a registry of supplementary members for the Web Application Manifest and the Web App Manifest - Application Information specs.

W3C MiniApp Manifest defines a "req_permissions" member that has an optional "reason" property. It might make sense to align here.

{
  "req_permissions": [
    {
      "name": "geolocation",
      "reason": "Find stores near you."
    }
  ]
}

(Note that this comes with a translation challenge, which is an unresolved Web App Manifest challenge, tracked in w3c/manifest#676.)

[mikewest]

Combining this with the app manifest isn't at all unreasonable. That said, given the mismatch between manifest scope (paths) and capability scope (origin), it's not clear to me that we can do so in all cases.

That said, I do periodically wonder whether we could reboot Origin Policy through a /.well-known/ manifest file whose scope was locked to /...

[tomayac]

The scope_extensions proposal complicates things further. But FWIW, I saw the scope (and the scope extensions) discussion only ever focused on navigation, but not permissions. Having permissions in a manifest is something developers are familiar with from native app development. On the other side, having permissions (and their justifications) in a .well-known file has the advantage of not requiring a full Web App Manifest, if you’re not interested in its web app aspects.

[mikewest]

But FWIW, I saw the scope (and the scope extensions) discussion only ever focused on navigation, but not permissions.

For most app manifest use cases, that makes sense. You're either in the app or not, and navigation controls that experience.

Capability's scope does not respect app boundaries, so it makes little sense to me for one app to declare a purpose that somehow maps to the entire origin. The origin, on the other hand, should be capable of making declarations that govern each of the apps it hosts.

Native app manifests have the advantage of encompassing the entirety of the app's scope. If we want to use web app manifests for permission declaration (and again, that's not at all crazy!), I think we can do it only in cases where the declaration is scoped to the origin.

[tomayac]

Native app manifests have the advantage of encompassing the entirety of the app's scope. If we want to use web app manifests for permission declaration (and again, that's not at all crazy!), I think we can do it only in cases where the declaration is scoped to the origin.

Many native apps extend their scope through web views. Thinking of the tagesschau app (that you are probably familiar with). From the main stream app page of news, they sometimes link out to web view content hosted on other institutions that gets represented inline (so most users presumably think of it as tagesschau app content, and not, say https://www.rbb-online.de/ content). In this case, it's not really a problem, because the extended scopes do not inherit the permissions from the main app scope. If anything, a user could believe that by installing tagesschau they grant permission access to all the web view origins. I reckon this is not very realistic, just wanted to make us think of web views in native apps, too.

[mikewest]

I agree with you that this is "not really a problem", and honestly feels tangential to the conversation above. :) You're right that the app can load pages into a webview, but those pages only have access to the set of capabilities the app has access to and delegates to them. This is similar to frames on a page in a browser that supports permission delegation. In both cases, the app is responsible for the capability's usage and availability, and seems like the entity that ought to be making declarations.