Creating a Statement List

Statements are hosted in a JSON-encoded statement list in a well-known location on a principal, as defined by the Asset Links Specification. A statement list contains one or more statements, and a principal can have only one statement list.

Statement list syntax

See the statement list syntax.

Statement list location

The statement list is hosted in a well known location that depends on the type of principal (the website or app making the statements).

Website statement lists

On a website, a statement list is a text file located at the following address:

scheme://domain/.well-known/assetlinks.json

Note the dot in the .well-known folder name.

Any response from the server besides HTTP 200 is treated as an error, and will result in an empty statement list. For HTTPS, any connection without a certificate chain that can be verified with the trusted root list will also result in an empty statement list.

Example

Here is an example statement list on a website: http://example.digitalassetlinks.org/.well-known/assetlinks.json

Android app statement lists

In an Android app, the statement list is a JSON snippet with the same syntax as a website statement file, but it is embedded in the strings.xml file, and referenced in the manifest as shown next.

In AndroidManifest.xml:

<manifest>   <application>     ...     <meta-data android:name="asset_statements" android:resource="@string/asset_statements" />     ...   </application> </manifest>

In res/values/strings.xml:

 <resources>   ...   <string name="asset_statements">     ... statement list ...   </string> </resources>

Example

Here is an example res/values/strings.xml snippet for an Android app that supports location sharing with the app (an Android feature not currently supported):

<resources>     ...     <string name="asset_statements">       [{         \"relation\": [\"delegate_permission/common.share_location\"],         \"target\": {           \"namespace\": \"web\",           \"site\": \"https://example.com\"         }       }]     </string> </resources>

Matching a target

Every statement is about a target. When you consume a statement, you must match the target in a statement against some entity in reality. If the statement target matches the entity, the statement applies. Here are the rules for determining if a target matches a given entity:

Website targets

For a website, the site scheme, host, and port must match exactly. Default ports for HTTP and HTTPS (80 and 443 respectively) are assumed implicitly; if a statement target describes http://www.example.com:80, then the website http://www.example.com is considered a match.

Example

Given the following statement target

"target": {   "namespace": "web",   "site": "https://www.google.com" }

The following URIs WILL match:

  • https://www.google.com/
  • https://www.google.com:443/
  • https://www.google.com/foo
  • https://www.google.com/foo?bar
  • https://www.google.com/foo#bar
  • https://user@password:www.google.com/

The following URLs will NOT match:

  • http://www.google.com/ (Wrong scheme)
  • https://google.com/ (Host name does not match)
  • https://www.google.com:444/ (Port does not match)

App targets

For an app, the certificate hash and package name of the target must exactly match the application.