Origin attestation from websites

[iinuwa]

This is more of a meta issue, not one we can really tackle on our own.

In #184, we talk about how if an origin attests to the running app, then we can skip permission prompts when that app requests credentials for that origin.

This would be very useful to automate that away from the user. Providing this would mean the user would have a higher signal-to-noise ratio for permission prompts, which is good for preventing prompt fatigue.

However, there are a few challenges we have to solve, that are somewhat interrelated:

• How does the site identify the app?
• How does the local machine match the attested identity to the running app?
• What is the format of the attestation? Is there another spec we can piggy-back onto, or do we have to do our own thing?
• Where is it located?
  • Can we host it with a centralized third-party?
• How can we convince large site operators to host special files for Linux apps (which have a small market share)?

[iinuwa]

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.

	Flatpak	Flatpak example	Snap field	Snap example
Distributor ID	collection ID	org.flathub.Stable	authority-id	canonical
Developer ID	doesn't exist		publisher-id	0IdVwWv66I2pI7X8D65kZ40Y8oYh6WqY
App ID	app ID	com.example.App	snap-id	KtwxgRlwCAVKFw92BUdt1WloH1Va3QPo
Signing Key	??		sign-key-sha3-384	BWDEoaqyr25nF5SNCvEv2v7QnM9QsfCc0PBMYD_i2NGSQ32EF2d4D0hqUel3m8ul

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