diff --git a/index.html b/index.html index 08d63b7..03991c6 100644 --- a/index.html +++ b/index.html @@ -240,6 +240,12 @@
- A web-app-origin-association file is a JSON file that can - be used to [=validate scope extensions=]. It confirm an association - between the origin it is in with one or more web applications. It - identifies apps uniquely by referencing manifest [=manifest/ids=]. -
-
- Given [=origin=] |origin:origin|, a [=web-app-origin-association=]
- file is expected to be downloadable from
- [origin]/.well-known/web-app-origin-association.
-
+ A web-app-origin-association file is a JSON file that can + be used to [=validate scope extensions=] or [=validate origin + migration=]. It confirms an association between the origin it is in + with one or more web applications. It identifies apps uniquely by + referencing manifest [=manifest/ids=]. +
+
+ Given [=origin=] |origin:origin|, a [=web-app-origin-association=]
+ file is expected to be downloadable from
+ [origin]/.well-known/web-app-origin-association.
+
+ Web Application Origin Migration allows a web application to indicate + to the user agent that it moved from one origin to another (within the + same site). This then enables the user agent to migrate an installed + web application while preserving the user's installation and potentially + their settings. +
+
+ The following example shows how a web application hosted at
+ https://old.example.com can be migrated to
+ https://new.example.com. Both origins must be
+ [=same site=] and must explicitly agree to the migration.
+
+ First, the old application's manifest can optionally include a + `migrate_to` member to signal to the user agent that it intends to + move (alternatively the old application can redirect to the new + application): +
+
+ {
+ "name": "My App",
+ "id": "/",
+ "migrate_to": {
+ "id": "https://new.example.com/",
+ "install_url": "https://new.example.com/install"
+ }
+ }
+
+ + Next, the new application's manifest includes a `migrate_from` member + to claim the migration from the old application: +
+
+ {
+ "name": "My New App",
+ "id": "/",
+ "migrate_from": [
+ {
+ "id": "https://old.example.com/",
+ "install_url": "https://old.example.com/install",
+ "behavior": "force"
+ }
+ ]
+ }
+
+ + Finally, the old origin must host a `web-app-origin-association` + file to definitively validate that it permits the new application to + take over. Without this file, a malicious new application could + claim to migrate from an old application without permission. +
+
+ {
+ "https://new.example.com/": {
+ "allow_migration": true
+ }
+ }
+
+ migrate_from member
+ + The [=manifest/migrate_from=] member is a [=list=] of either + [=strings=] or [=ordered maps=] that identifies the old web + applications that are being migrated from. +
++ If an entry is a [=string=], it is treated as the [=manifest/id=] of + the old application. +
++ If an entry is an [=ordered map=], it can have the following members: +
+id: A
+ [=string=] representing the [=manifest/id=] of the old application.
+ install_url: A [=string=]
+ representing a URL of a page that links to the old application's
+ manifest. A user agent can use this field to fetch the manifest of
+ the old application in order to apply updates even if every other
+ URL that is part of the old application redirects to the new
+ application.
+ behavior: A
+ [=string=] that can be either `"suggest"` or `"force"`. This is a
+ hint to the user agent that might influence how forceful the UI is
+ that the user agent presents to the user to tell them about the
+ migration.
+ migrate_to member
+ + The [=manifest/migrate_to=] member is an optional [=ordered map=] that + proactively signals a migration to a new application. It has the + following members: +
+id: A
+ [=string=] representing the [=manifest/id=] of the new application.
+ install_url: A [=string=]
+ representing a URL of a page that links to the new application's
+ manifest. The manifest on this page needs to include a
+ [=manifest/migrate_from=] field that points back at this application
+ for the migration to be processed.
+ + To validate origin migration, given [=URL=] + |old_manifest_id:URL| and [=URL=] |new_manifest_id:URL|: +
++ To process the `migrate_from` member, given [=ordered + map=] |json:ordered map|, [=ordered map=] |manifest:ordered map|, and + [=URL=] |manifest URL:URL|: +
++ To process the `migrate_to` member, given [=ordered + map=] |json:ordered map|, [=ordered map=] |manifest:ordered map|, and + [=URL=] |manifest URL:URL|: +
++ To prevent malicious actors from silently taking over applications (e.g., a simple calculator updating itself to mimic a banking app), the [=validate origin migration=] algorithm enforces a two-way handshake. Both the new and the old application origins must explicitly agree to the migration via the [=web-app-origin-association=] file. +
++ Furthermore, migrations are restricted to be [=same site=] to ensure they are used for legitimate rebranding and architecture changes within an organization's control, rather than transferring ownership to unverified third parties. +
++ User agents should consider including an explicit user confirmation dialog as part of the migration flow, especially if an update to security-sensitive fields (such as the app name and icons) is included. +
+