Some unedited notes: beware

Unlike other ecosystems, there are multiple packaging formats and distributors for apps on the XDG platform. We need to define globally unique app IDs for each of these for using signed metadata.

Terms

• ecosystems: app packaging format and ID handling rules (e.g. uniqueness, partitioning)
  • e.g. Snap vs. Flatpak
• distributor: different "app stores" with different policies, e.g.
  • Snap: snapcraft.io vs. a private snap store, or
  • Flatpak: flathub.org vs Fedora Flatpak repo
• developer: person who writes the app and publishes to a distributor

Uses

• Credential providers storing associations with an app.
  • If Bitwarden wanted to map a credential to an App, then it would be something like: xdg-app://<global app id>,
• Credential manifests
  • If a site wants to host a well-known manifest to associate to an app, then it should use a globally unique ID so that the local client can have high confidence that it's talking about the same app
• The trust should be persisted across app versions
  • Other ecosystems do this based on app signing keys, which makes sense
  • Flathub currently signs all apps with the same signing key, which may be problematic, but not in scope for changing here.

Non-goals

• The trust is local: the user may choose to set up new repositories, and those repositories should be trusted. So we assume that there is a trusted local binding between a distributor ID and the installed package.
• So it may be possible for a local machine to set up, for example, a local flathub remote with signing keys that don't actually belong to Flathub, but that would be up to this to change

Flatpak

Distributor: collection IDs
Developer ID: developer_id from AppStream metadata, but only if verified, otherwise empty
App ID: app ID
Signing key: SHA-256 hash over the remote's GPG public key block?

• signing over the whole block means that we're leaving open the attack where an attacker generates a private key, and then twiddles with the user ID or other variable fields in the key block, signs the block over and over until it generates a matching SHA-256 hash.
• I suppose they could do that by just generating a new private key until it matches, which is just as infeasible. This probably doesn't matter

e.g. xdg-app://flatpak:org.flathub.Stable//com.example.App
with unverified developer, and
e.g. xdg-app://flatpak:org.flathub.Stable/com.example/com.example.App
for verified developer

Snap

Distributor: snap authority, e.g. canonical for main snapcraft snap store
Developer ID: publisher-id: canonical for Ubuntu's Snaps, and 32-character alphanumeric string for others
App ID: Snap ID: 32-character alphanumeric string
Signing key: sign-key-sha3-384: base64-encoded SHA3-384 hash over the signing public key.

Manifest example

based on web application manifest incubation spec

// /.well-known/xdg-app-association
{
// scope must be root to associate with the whole site
"scope": "/",
// ...
"related_applications": [
 {
 "platform": "snap",
 "id": "canonical/0IdVwWv66I2pI7X8D65kZ40Y8oYh6WqY/KtwxgRlwCAVKFw92BUdt1WloH1Va3QPo",
 "fingerprints": [
 {
 // same value as in snap metadata
 "type": "sign-key-sha3-384",
 "value": "BWDEoaqyr25nF5SNCvEv2v7QnM9QsfCc0PBMYD_i2NGSQ32EF2d4D0hqUel3m8ul",
 }
 ],
 "permissions": [
 // IDK if we need a version here...
 "credentials/v0",
 "launch": 
 ]
 },
 {
 "platform": "flatpak",
 "id": "org.flathub.Stable/com.discordapp.Discord",
 "fingerprints": [
 {
 // SHA-256 hash over signing key (GPG v4 public key block)
 "type": "sha256-gpg-v4",
 "value": "c504fa5dc891df6cfcc10021dd9addf08459007f1787f40b9c6fd3c7e58416ea",
 }
 ]
 }
]
}

Notes

Including the Snap developer ID means that the site is bound to developer ownership; if the developer transfers ownership, the manifest must also be updated. (Are permissions bound to the developer ID? probably should be...), and permissions must be updated

Developers/owners aren't a real concept in Flatpak (though it does exist in Flathub), so we can't do that there.

Basing on the Web Application Manifest might not be super useful